When is an Explorer not an Explorer?

RJGray found another error in the NoReplyAll add-in: basically, visiting the Today Page causes the add-in to throw a bunch of exceptions which seem to be triggered by accessing the Explorer Selection when that page is showing instead of an Explorer - the lazy instinct is to add a try...catch block, which does indeed make the error messages go away. While that's not particularly satisfactory, a web search for the message "The Explorer has been closed and cannot be used for further operations" unfortunately produces no better solution. I did think of trying to identify the Today page but couldn't come up with a obvious and reliable way to do it (one thought was a string match on the name, but how then would I deal with localization, which tripped me up in the past).

In an earlier post I showed some code to get hold of the current MailItem from the Outlook main window: my fix is to replace that with:

 Outlook.MailItem item = null;
var explorer = control.Context as Outlook.Explorer;
if (explorer != null)
{
    Outlook.Selection selection = null;
    try
    {
        selection = explorer.Selection;
        if (selection.Count == 1)
        item = selection[1] as Outlook.MailItem;
    }
    catch(COMException ex)
    {
    }
    if (selection != null)
        Marshal.ReleaseComObject(selection);
    Marshal.ReleaseComObject(explorer);
}

That does seem to do the trick - it did briefly cross my mind to wrap all of the ribbon invokes methods in try...catch blocks, to ensure that no errors make it to the user, and maybe I should do that for a more robust release, but I want to see what new things break, so that I can learn more about how to fix them!

New release of the add-in coming soon...