ATL / COM / Automation / ActiveX VC++ 2005 Advice?

June 14, 2007 10:39 PM

ATL, COM, Automation in VC++ 2005 - Help me make sense of it all!

I'm creating an Outlook 2003 / 2007 Add-In in VC++ using VS 2005. I've been referencing these two excellent Code Project articles, but I want to go a little deeper...

Though I'm a seasoned developer, I've been away from C++ and COM / Automation for a while. I need a book / website that I guess I would describe as intermediate-level; more than an "Introduction to VC++" but less than "ATL Internals" (which is a great book but is just a little over my head).

I want to know things like:

-- When I use an #import statement, what is raw_interfaces_only doing? Do I need it for my plugin (it's used in the example code in the articles I mentioned above)? Why?

-- How can I avoid calls like HRESULT hr = Session->get_Folders( &Folders );
And instead just call Folders = Session->Folders;
More like a normal VC++ app.

-- What if I'm trying to #import a file that's not on the user's computer? I.e. can I detect if they have Outlook 2003 installed vs. Outlook 2007 and #import accordingly?

-- When do I use a CComPtr and when do I use a CComQIPtr??? Can I get by without using them at all?

-- In what ways can VS 2005 help me to generate code for my add-in? Do I really have to modify the sink map and COM map by hand to add event sinks?

BTW no I don't want to use VB and no, I don't want to use C# or the CLI.

Thanks in advance for any help or advice. :D

posted by blahtsk to computers & internet (7 comments total)

I'm really not arguing with you, but I'm surprised that someone would willingly pick COM and c++ over CLI, except for thoes situations where performance is not only critical, but being pushed to the limit. Especially someone that wants to avoid by-reference calls to populate a local variable... hresult/by-reference is just so COM/C++.

(I'm willing to bet it's internally more complex than just handing over a known memory address, hence the need for a result, and the use of the get_ convention. If it was a .NET library you could just reflect it and find out what was going on!)

I say this as someone that slams into the performance limitations of the CLR and whose team uses a fair amount of unsafe code and C++/CLI to get around them.

I'm not familiar with office automation since VBA for Access in 96-97. So maybe the .NET hooks suck ass, I wouldn't know. But since COM is such a general hellhole in comparison, and MS is so into .net, that would also surprise me.
posted by flaterik at 11:09 PM on June 14, 2007

The msdn reference for attributed C++ is good.

oleview from this is also nice for figuring out exactly what you put in your type libraries.

For you're specific questions:

-- raw_interfaces_only tells the compiler to not generate any wrapper code, just the raw COM function hooks. This is why you're only getting raw COM functions, not nice wrapped ones.

-- #import has nothing to do with the user's computer. It's entirely compile time. .tlb goes in, some headers and code comes out

-- You can get by without any sort of smart COM pointer wrapper class. You just have to count references yourself.

on preview:
nah, there's nothing fancy going on with the HRESULT get_foo thing, he's just not telling the compiler to generate pretty wrappers. At worst, you get an extra object copy that'll probably get optimized away anyway.

But yeah, there's almost certainly no performance reason to use COM instead of CLI for whatever you're doing. You're program's going to spending most of its time waiting for disk or memory anyway.
posted by Diz at 11:18 PM on June 14, 2007

You can get by without any sort of smart COM pointer wrapper class. You just have to count references yourself....there's nothing fancy going on with the HRESULT get_foo thing,

It's not counting a reference? Doing some sort of permission check? NOTHING???

Sorry for the derail. The interface just SO STRONGLY IMPLIES something is going on there, and I've actually gotten used to APIs that are at least vaguely self documenting.

This is why I hate COM and have purged all understanding of its working from my brain.
posted by flaterik at 11:26 PM on June 14, 2007

Let me say:

-- When I use an #import statement, what is raw_interfaces_only doing? Do I need it for my plugin (it's used in the example code in the articles I mentioned above)? Why?


When you import a type library, visual studio generates wrapper functions. I believe that these wrapper functions may throw exceptions in one case. In another case, the wrapper function are of the form GetValue, which then calls get_Value(&param). If you say only raw interfaces, you get the normal COM method call without any wrapper functions.

-- How can I avoid calls like HRESULT hr = Session->get_Folders( &Folders );
And instead just call Folders = Session->Folders;
More like a normal VC++ app.

See above.

-- What if I'm trying to #import a file that's not on the user's computer? I.e. can I detect if they have Outlook 2003 installed vs. Outlook 2007 and #import accordingly?

#Import has nothing to do with object creation. You create an object using CoCreateInstance, and if this fails, you know the object is not installed. Just use the correct guid. #import is equivalent to "include", but it generates the header files from your source, and does not just include them. You can #import your header files from a .dll or from a .tlb.

-- When do I use a CComPtr and when do I use a CComQIPtr??? Can I get by without using them at all?

PLEASE, PLEASE, Use them! If you do not use them, you WILL have serious memory bugs in your application. It is VERY difficult to properly count references yourself, and CComPtr helps you do this. QI is the same as CComPtr, it just helps you query the interface using a more convenient syntax. Instead of IObject*, write CComPtr. There is no other difference, but you don't need to AddRef or Release anymore.

I cannot emphasize enough how you have to do proper reference counting, particularly when interacting with external applications. So learn to use CComPtr.

-- In what ways can VS 2005 help me to generate code for my add-in? Do I really have to modify the sink map and COM map by hand to add event sinks?

Right click on interface in class view, select AddFunction.

BTW no I don't want to use VB and no, I don't want to use C# or the CLI.

C# is a terrible pain. It takes 15 minutes to install the .NET runtimes, and requires 20 extra MB in my installer. To make a sex analogy, Assembler is like barebacking, C++ is like wearing a thin condom, and C# is like wearing a sock.
posted by markovich at 1:49 AM on June 15, 2007

mark,

All Vista users already have the .NET runtimes, and I think they're pretty common on XPSP2.

Have you seen IronPython? It's become one of my favorite ways to write things.
posted by effugas at 6:37 AM on June 15, 2007

At the moment, there are more Windows 2000 users than there are Vista. Vista is about 5% of the market, and it's not growing amazingly fast. For the next 2 years at least, Windows XP is going to be the dominant OS. XPSP2 is not a pushed update. It's an optional update, and most people are not doing it.

I tried IronPython. I spent a few days making the decision on what programming language to use for my new project, and ended up deciding on IronPython for probably the same reasons you did.

After installing it, I tried to load a picture into a picturebox, and it crashed. I promptly switched to C#. I really don't want to deploy an application where there may be bugs in the runtime a.k.a unfixable bugs.

The .NET runtimes are a pain to install. I wish Microsoft had just given us a linker.
posted by markovich at 7:11 AM on June 15, 2007

Funny, I only write server software now so I've not thought about the runtime installation in a long time.

As I recall the redistributable is pretty painless to install, but our images already have the 3.0 runtime on them before any application installation comes along anyway.

I love C#. I mostly love .NET but they need to fix large address space long term high usage memory management (which they admit themselves).
posted by flaterik at 6:40 PM on June 15, 2007