Title: Message
 
I'm still taking baby steps into COM and ATL and I've run into my next problem. I'm writing a server that is instantiated by an executable for which I have no source code. I can trigger the executable to create an instance of my server; when something goes wrong, the only error message I get from that executable is the COM error code. I'm past the stage where I kept getting 'class not registered', so that's good; thing is, I now get 'interface not supported'. I do have an IDL file with a bunch of COM interfaces but I don't have any documentation on which interface I should implement (and how). So my first idea was to override the QueryInterface() method in my ATL object and log the contents of the riid parameter to a file. I hacked the END_COM_MAP macro a bit and it compiled ok but when I triggered my blackbox executable I got the 'interface not supported' again (as was to be expected) but worse, no file was created (so my QueryInterface function on the ATL object wasn't called). Now I was thinking, maybe I should first try to override the QueryInterface of my CoClass and see if that works? But how would I do that? Is there maybe another way for me to find out which interface is requested? Thanks. 
This is a common problem in creating ATL objects, and like all common problems in this task, ATL comes to rescue.
 
ATL has some built-in debugging support.  One of them is the _ATL_DEBUG_QI macro.  Just #define this macro before all ATL headers (at the top of stdafx.h if you use it) and recompile.  ATL will trace all calls to QueryInterface( ) on all interfaces for you automagically in a useful manner.
 
But you will have lots of problems if there's no doc on the interfaces you must implement.  Each interface has a purpose, and each method has a purpose too.  It's tough to guess them all over on your own.  And it's prone to any number of errors.  The least thing that they should provide for you is a commented IDL with helpstring's all over the place, but that wouldn't replace a nicely written piece of documentation.
_______________________________________________
msvc mailing list
[EMAIL PROTECTED]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription 
changes, and list archive.

Reply via email to