It makes removal automatic, but with Outlook I'm a firm believer in belt
plus suspenders.

I don't pay attention to removal mode but if Outlook is exiting you won't
get an On_Disconnection event unless all of your Outlook objects have
already been released. A classic Catch-22 situation that's only now fixed in
Outlook 2007. So we monitor for Explorer.Close and Inspector.Close and if
there are no additional Explorers or Inspectors then Outlook is closing and
you release all your Outlook objects so On_Disconnection can fire.

If the user disconnects the addin I call my release code from
On_Disconnection and that checks to see if my global Outlook application
object has already been released. If so I just exit that procedure
gracefully.

One exception to the temporary rule is WordMail. Word doesn't honor the
temporary setting although it doesn't fire an error if you set it. So for
WordMail you must explicitly delete the buttons/toolbars you've added as
well as deal with the CustomizationContext so the user doesn't get your
buttons/toolbars when Word (not WordMail) is used and so the user doesn't
get a prompt to save Normal.dot when they exit if set to prompt for saving
changes to Normal.dot.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Mark J. McGinty" wrote in message
...

"Ken Slovak - [MVP - Outlook]" wrote in message
...
I always just delete the command bar, but I also set it as temporary when
I
create it.

Thanks for the reply, Ken.

A couple more questions, if I may... The temporary flag prevents the
bar/button definition from being persisted? Wouldn't that tend to make
removal unnecessary?

I take it you don't pay any attention to RemoveMode when the AddIn
disconnects?


Thanks,
Mark