Outlook New Explorer Hook

When developing our add-in, we tried to add a callback on the creation of a new Explorer. Something like:

Application.Explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

Unfortunatly, after a new explorer or two were created, our callback was no longer called by outlook.

What made this more consistent was:

Application.Explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

GC.Collect();

Now, the NewExplorer callback was never called !!

The workaround: Create a global reference to the Explorers object, such as

Explorers explorers;

void Startup()

{

explorers = Application.Explorers;

explorers.NewExplorer += new ExplorersEvents_NewExplorerEventHandler(Explorers_NewExplorer);

....

}

It seems that without this reference, the Explorers object, together with my callback, were all collected by the GC.

This would be a good opportunity to thank my co-worker Arina for figuring this out.

Outlook Add-Ins can be tricky

Lately I have been doing some development of an outlook add-in, and I learned that this can be challenging. I would like to share on this blog some of my experiences during this development.

So here is one of the more "fun" experiences:

As you probably know, it is possible in outlook to open more than one explorer window (the one with list of mail items, or the calendar, etc).

Another feature of outlook is that when you exit while there are unsent items in the outbox, you get a message box notifying you, and asking if you want to exit without sending, or send and then exit.

I had a bug: When the add-in is installed, and the user exits outlook, and there are unsent items in the outbox, the user gets asked if he really wants to exit not once, but several times, as many as the number of explorers that were ever opened in the session.

This is an annoying bug. It also doesn't seem connectd to what my add-in was doing, and this was weird. I scrambled to figure out the source of the bug by cutting out code from the add-in until I came to a simple addin reproducing the bug and containing these lines only:

private void SidebarAddIn_Startup(object sender, System.EventArgs e)

{

foreach (Explorer explorer in Application.Explorers)

{

}

}

A puzzlement indeed.

After a lot of pondering I came to the conclusion that the foreach() generates Explorer objects that are COM wrappers, and contain reference to the underlying Explorer objects. This keeps COM Explorer objects roaming around, and is probably the cause of this bug. And a simple workaround:

private void SidebarAddIn_Startup(object sender, System.EventArgs e)

{

foreach (Explorer explorer in Application.Explorers)

{

}

GC.Collect();

}

and the bug is solved.

Of course in my add-in, this did not actually work. It turns out there are more operations that leak managed Explorer objects. One of them is adding a CustomTaskPane to an explorer and removing it.

Good luck to all Outlook add-in developers....

Noam