Save CommandBar-Settings on exit...

[Heinz-Josef Bomanns]

Hi,

i've added a commandbar to the main explorer. It's only needed there,
not in other explorers, so i don't use any explorer wrapper stuff and
create the commandbar in "OnConnection". When the user quits Outlook i
need to save state and position (docked, not docked, row etc.) of the
commandbar to restore it on next startup. I've tried to access the
commandbar in "OnDisconnection" or in "OnBeginShutdown" or via
"Outlook.Quit" and "Explorer.Close" but all fails 'cause the main
explorer is already closed then. Is there really no way to catch the
quit with having access to the main explorer and the commandbar?
Thanks for any hint...

 

[Ken Slovak - [MVP - Outlook]]

Hi Heinz-Josef,

You should be able to use Explorer.Close whether or not you are using an
Explorer wrapper. That's what I do when I have to save a toolbar position
setting. I read the previous position settings when I create the toolbar in
NewExplorer (I save the existing values to the registry) and save them in
Explorer.Close.

In my main class module:

Private WithEvents cbStd as Office.CommandBar
Private WithEvents objExpl As Outlook.Explorer

In NewExplorer and in Init code since an existing Explorer won't fire
NewExplorer when the COM addin starts up:

Set objExpl = objOL.ActiveExplorer
Call CreateButtons

CreateButtons:
'assign cbStd and create all the buttons
Call GetToolbarPosition

In Explorer.Close:

If Not (cbStd Is Nothing) Then
Call SaveToolbarPosition
EndIf

 

[Heinz-Josef Bomanns]

Hi Ken,

You should be able to use Explorer.Close [...]

Thanks Ken, that und your marvelous button wrapper solved the problems
I guess my mistake was to do all the init and reset stuff in
"OnConnection" and "OnDisconnection". After moving all the stuff into
a "gBaseClass" and using "InitHandler" und "UnInitHandler" the right
way it now works like a charm. Thanks again...

 

[Ken Slovak - [MVP - Outlook]]

You'll find that by the time On_Disconnection fires that all Outlook objects
are out of scope. In fact, in a COM addin where Outlook is closed by the
user the On_Disconnection event won't even fire while any Outlook objects
haven't been released. It will fire after the UnInitHandler because at that
time all the Outlook objects have been released.

The exception to that rule is the case of RemoveMode = ext_dm_UserClosed,
then On_Disconnection will fire even if Outlook objects haven't been
released.

This problem is a famous Catch-22 with Outlook addins, On_Disconnection
won't fire unless all your Outlook objects have been released. That's why
the method shown in the ItemsCB COM addin sample on the Resources page at
www.microeye.com was developed to monitor the closing of Explorers and
Inspectors to know when to release the Outlook objects.

Hi Ken,

You should be able to use Explorer.Close [...]

Thanks Ken, that und your marvelous button wrapper solved the problems
I guess my mistake was to do all the init and reset stuff in
"OnConnection" and "OnDisconnection". After moving all the stuff into
a "gBaseClass" and using "InitHandler" und "UnInitHandler" the right
way it now works like a charm. Thanks again...


--

So long...
...Bomi

!!! EMail??? Please use Reply-To address and remove underscores (_) !!!

 

[Heinz-Josef Bomanns]

Hi Ken,

[...] On_Disconnection event won't even fire while any Outlook objects
haven't been released [...] The exception to that rule is the case of
RemoveMode = ext_dm_UserClosed, then On_Disconnection will fire even if
Outlook objects haven't been released [...] ItemsCB

Thanks for sharing this comprehensive infos, it's much appreciated -
step by step i'm getting into all this do's and dont's ,-)