The SendTo function opens an Inspector in Outlook but no Explorers. If you
instantiate your COM addin in the On_Connection event and there are no
Explorers you might have a problem disconnecting your addin and releasing
your objects thereby hanging Outlook and leaving it in memory.
There is a bug in the Outlook COM addin model in the On_Disconnection event.
It won't fire if Outlook is closed if there are any Outlook objects
instantiated. After all Outlook objects are released the On_Disconnection
event will fire. It fires correctly if the user disconnects the addin from
the COM AddIns dialog.
I suspect that's the problem you might be running into. The workaround many
of us use is not to instantiate our COM addins unless an Explorer is
present. We also use a little utility called AddInMon that runs in the
background and checks for a Windows window that is only present when Outlook
has an Explorer. When that condition is true AddInMon toggles the Connect
bit of every addin that has an AddInMon DWORD value in the registration key
(MyAddin.Connect) for the addin. This results in the addin receiving the
On_Connection event again and because there is now an Explorer present the
addin instantiates itself.
There's a COM addin template written in VB 6 that demonstrates this as well
as many other workarounds for Outlook COM addin bugs and oddities. It's
called ItemsCB and it can be downloaded from the Resources page at
www.microeye.com. If you have access to the VB 6 environment I suggest that
you download this template and examine it to see how it works.
There are also references to a lot of .NET COM addin information at
MicroEye. There's a link to that on the Resources page there.
