COM Addin cannot access the CommandBars collections

[Michael Hoehne]

I have a very strange situation here and hope that someone can confirm this behaviour or provide a solution.

My addin works fine as long as I start Outlook in the usual way, meaning clicking the Outlook Icon and launching the full application. In this scenario I can modify the ActiveExplorer's command bar (menu items, toolbars, etc.)

Now, when I first open a .msg file from the filesystem, Outlook starts and the addin is loaded. However at this time there's no active explorer, what is expected, because the only visible thing on the screen is an inspector object.

To create the menu entries (and of course the associated event handlers), I hook into the NewExplorer event of the Application.Explorers collection and do receive the event when Outlook is launched. The newly created Explorer object is passed to the event routine and I expected that I can simply add my menus to its CommandBars collection. BUT: any call to explorer.CommandBars throws an error with some useless text (error executing the operation).

Does anyone have a solution for this or can anyone confirm this to be a bug in Outlook?

Thanks
Michael

 

[Dmitry Streblechenko \(MVP\)]

At the time NewExplorer event fires, the explorer has not yet been fully
initialized. Wait for the Explorer.Activate event and add your
toolbars/buttons in that event handler if they are not already there.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

I have a very strange situation here and hope that someone can confirm

this behaviour or provide a solution.

My addin works fine as long as I start Outlook in the usual way, meaning

clicking the Outlook Icon and launching the full application. In this
scenario I can modify the ActiveExplorer's command bar (menu items,
toolbars, etc.)

Now, when I first open a .msg file from the filesystem, Outlook starts and

the addin is loaded. However at this time there's no active explorer, what
is expected, because the only visible thing on the screen is an inspector
object.

To create the menu entries (and of course the associated event handlers),

I hook into the NewExplorer event of the Application.Explorers collection
and do receive the event when Outlook is launched. The newly created
Explorer object is passed to the event routine and I expected that I can
simply add my menus to its CommandBars collection. BUT: any call to
explorer.CommandBars throws an error with some useless text (error executing
the operation).

 

[George Sugari]

Hi Michael,
There is a solution to that. You don't have to use a timer just call the
method to create the toolbar from the InitHandler if there is an Explorer.
I'm using an Explorer wrapper class and I add the Explorer to the collection
the first time Outlook is started.

Friend Sub InitHandler(olApp As Outlook.Application, strProgID As String)
On Error Resume Next

Set objOutlook = olApp 'Application Object
Set colExpl = objOutlook.Explorers 'Explorers Object

If colExpl.Count >= 1 Then
Set objNS = objOutlook.GetNamespace("MAPI")
Set objExpl = objOutlook.ActiveExplorer 'Explorer Object
Set colInsp = objOutlook.Inspectors 'Inspectors Object

AddExplorer objOutlook.ActiveExplorer
colExplorers(CStr(lngExplorerID - 1)).CreateToolbar
End If
End If
End Sub

This works but I'm still having a problem when Outlook is closed with an
Inspector window opened. In this case Outlook 2000 is not closed, it is
still in memory and when I open it again because my AddIn is not unloaded
_NewExplorer event fires but the Explorer object cannot be referenced and
trying to access Commandbars collection crashes Outlook. I know that i can
uload the Addin when the Explorers count is 0 but in that case my Addin will
not load when the users opens Outlook again.

Does anyone know a work aorund for this?

Thanks,
George

Well, thanks for your answer. But it doesn't work after the first Activate

event as well. Only if I switch do another application to deactivate Outlook
and then switch back to the Explorer again, another Activate is fired. At
this time the menu initialization works fine.

As a workaround I create a timer when receiving the first Activate event

that fires every 2 seconds until a "valid" Explorer object is present,
meaning that I can do the menu customization.

 

[Dmitry Streblechenko \(MVP\)]

Why do you need the second Activate event? Add the toolbars/buttons as soon
as the first Activate fires.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

Well, thanks for your answer. But it doesn't work after the first Activate

event as well. Only if I switch do another application to deactivate Outlook
and then switch back to the Explorer again, another Activate is fired. At
this time the menu initialization works fine.

As a workaround I create a timer when receiving the first Activate event

that fires every 2 seconds until a "valid" Explorer object is present,
meaning that I can do the menu customization.

 

[Chris Hubbard]

Why do you need the second Activate event? Add the toolbars/buttons as soon
as the first Activate fires.

Funny that this came up. I am currently working on this exact
problem.

In my experience in trying to solve this, the Explorer is not *always*
completely ready when the Activate event fires. I am customizing the
Standard Explorer toolbar (maybe part of my problem) in the following
manner:
* add a item to the New Item popup
* add a popup (at a specific position)

One my development machine everything works fine. On one of our users
machine, the item is not added to the New Item popup and the added
popup is not in the correct position.

My addin is written in C++ (using the Vernoter sample as a starting
point). That sample didn't correctly handle the case were Outlook is
started without an Explorer window (e.g. ActiveSync starts before
Outlook). So when the Addin starts up, I hook the
ExplorersEvents::NewExplorer event. When this event fires, I create a
temporary object that hooks the ExplorerEvents::Activate event. When
this event fires, I call a method to create the "base" class that
hooks into the Explorer Window.

Using this method, I don't have to use the AddinMon spying app that is
required for VB addins. A similar technique could be done with a
helper class that does the ExplorersEvent hook and is created in the
Addin Designer code.

The only problem is that this is not consistent. The Explorer
CommandBars still do seem to be 100% complete at this point. I guess
I can do the timer. That seems a hack. But after all, this is an
Outlook Addin so it is par for the course. Does anyone know of a
better event to hook off of instead of ExplorerEvents::Activate?

Thanks,
ChrisH

 

[George Sugari]

Dmitry,
I think what Michael is trying to say is that the Activate event does not
fire when you first open Outlook

George

 

[Dmitry Streblechenko \(MVP\)]

Correct, it does not. In this case you should loop over all explorers in the
Application.Explorers collection on startup and try to add the toolbars. If
any of the calls fail, you can wait for the Activate event.
Works just fine for me.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool