deleting CommandBars

[Mark J. McGinty]

Is there any good reason to delete all of the Controls in a CommandBar,
before deleting the CommandBar itself?

-Mark

 

[Ken Slovak - [MVP - Outlook]]

I always just delete the command bar, but I also set it as temporary when I
create it.

 

[Mark J. McGinty]

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

 

[Mark J. McGinty]

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?

Hmm, trying to remove them when (RemoveMode <> ext_dm_UserClosed) seems to
be a moot point, since that is the only way OnDisconnection fires while a
valid Explorer exists. I also noticed that removing CommandBars in
Explorer_Close fails with error: "The Explorer has been closed and cannot
be used for further operations. Review your code and restart Outlook."

I made both the buttons and the bars temporary (and manually deleted the old
bar.) The buttons go away when OL exits, but the bar persists, even when
the temp parameter to CommamdBars.Add is True.

Where do you remove your CommandBars?


-Mark

 

[Ken Slovak - [MVP - Outlook]]

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]]

Is Outlook truly exiting? I never get persistent toolbars that weren't
supposed to be there. I do use Explorer.Close.