OK, it was my fault.

First, the IID I should have been using for CoCreateInstance() is
"Document", not "IFoo". This makes a little sense if you think of the clsid,
L"IFoo.Document"... I can't put the reason into words exactly, but there you
go.

I actually wondered about this and had tried it; the call to get the
'interface' (it did get retrieved as if it were an interface, but I'm a
little confused about why it's not IDocument... so I'll keep quiet before I
munge this any further!) /succeeded/, as opposed to trying to retrieve IFoo
which failed with E_NOINTERFACE.

The problem was, when I tried to use that smart pointer to call the method,
the code access-violated... and I was led up the wrong path thinking that it
was something wrong about the smart pointer I had created, and so Document
couldn't be right.

Well, it wasn't; the problem was that I was calling CoInitialize() and
CoUninitialize() within the routine which created the smart pointer and used
it. Trouble is, that meant that CoUninitialize() was being called before the
end of the routine, and thus before the smart pointer had gone out of scope
and tried to call Release()... so all hell broke loose.

The only reason I found out was because the book "Inside Visual C++" led me
back to focus on Document, and then it finally clicked what I'd done wrong.



Now, just so you don't get away without listening to more COM crap {;v)...

There was one final gotcha - nothing tragic this time, just an irritation.
The method I had defined tried to return a long integer to the calling
code - something non-zero to indicate success, or zero for failure. The VB
client handled it just fine, but for some strange reason the VC client kept
getting back zero - even though the server itself confirmed that it was
sending back non-zero.

I traced it a little and found that the inline method defined by the .tli
file generated by the #import returns zero from the _com_dispatch_method()
call it makes. Now, this is no big deal since it's easy to fix: simply add
another out parameter to the method and forget the return value. I also seem
to remember reading somewhere that you should never return anything from a
COM call except an HRESULT anyway - perhaps this is the reason? Anyway, I'm
a happy bunny now (until tomorrow, no doubt), so I'll leave you all to enjoy
your Sunday {:v)

--
Jason "Should Be A COM Expert In About 20 Years" Teagle
[EMAIL PROTECTED]




Reply via email to