Dmitry Streblechenko (MVP)
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
I don't really understand what you mean by "I have an outstanding call to an
"o" and I destroy it.". To be able to call a method on a COM object, you
need to keep a reference to it, which means it is still referenced.
Unlike regular classes (.Net, C++, Delphi, etc), you do not destroy COM
objects. There is simply no way to do that. One of the basic COM principles
is that the COM object itself is responsible for its own destruction. Again,
COM object is not a class. Even if it looks like one (v-table, etc). You can
dereference the object, but you cannot destroy it.
I am not sure what you mean.. COM has absolutely no notion of "busy". You
call AddRef, the object increments its internal reference counter. You call
Release, it decrements it. If it drops down to 0, the object is supposed to
destroy itself. Or do whatever it pleases. There is no such thing as "busy",
especially when it comes to the code that consumes the COM object.
Again, it has nothing to do with .Net or COM. It is Office trying to be
smart and figure out whether it should kill itself or keep itself alive even
if you completely dereference it.
That logic is different in different versions of the Office or maybe
Windows, but it absolutely does not depend on who the caller is. COM objects
neither know nor care.
This is a sideeffect of how COM events are supported in .Net. Your event
handler is an object that keeps an internal reference to the COM object in
question. So even if you release your explicit variable, the object is still
referenced by the event handler. Strictly speaking GC should be able to
detect circular references (it does that for the .Net objects), but
apparently it does not work quite well with the COM objects.