Problem with multiple wordmail editors in Outlook 2003

[Eiríkur Fannar Torfason]

I have a shared add-in written in C# compiled for .NET Framework 2.0. The
add-in has an InspectorWrapper which detects when Word 2003 is the mail
editor, finds a CommandBar created by the same add-in (in the word process)
and subscribes to the click events of its buttons. This has been working fine
for several years. Recently we were adding new functionality; a new button
was added to the toolbar and its state must change according to the user's
actions. If the user for example clicks on one button in the wordmail editor,
the inspectorwrapper gets the click event, shows a dialog where the user
makes a selection, that selection is then stored as a custom property on the
MailItem in Outlook. After that we want to enable the new button and assign a
tooltip to it. We are doing this from the InspectorWrapper and it works if
the user just writes one e-mail at a time. When the 2nd wordmail editor
appears, we start getting COMException (0x800A01A8) errors when the
winword.exe instance of the add-ins tries to modify the contents of the
CommandBar. If I comment out the code in the inspectorwrapper that modifies
the state of the new button, everything goes back to normal.

I've therefore tried two different approaches.
1. In the InspectorWrapper, use the WordEditor property to access the Word
document and assign a string to its .Variables collection and then read that
string from the Winword.exe instance of the Add-in. This also resulted in
comexceptions when multiple wordmail editors were opened, only now in the
InspectorWrapper code that iterates through the CommandBars and reads their
names.

2. From the winword.exe instance get a hold of the MailItem from the
Document.MailEnvelope.Item property, look for the custom property in order to
find out whether the button should be enabled or disabled. This also resulted
in COMExceptions when multiple wordmail editors were open.

Both approaches however worked fine when there was just a single wordmail
editor.

Is it somehow possible to pass information from the outlook.exe process to
the winword.exe process in a way that doesn't break down when you have
multiple wordmail editors open?

 

[Ken Slovak - [MVP - Outlook]]

That should be workable all from the Outlook addin code. When you create the
WordMail UI are you assigning custom Tag properties to the UI elements that
differ from one Inspector to the next? It almost sounds like you aren't if
things are working with only 1 Inspector open but not more.

I assign a custom Tag that ends with a wrapper Key value that's always
unique to that Outlook session. Then I can check each tag and see if the UI
piece belongs to that Inspector or even to WordMail. I can then get the UI
element and change the state.

I've done that with sets of toggle buttons in WordMail items where there
might be 3 or 4 or more buttons that toggle state depending on settings,
clicks and dialog results and I haven't seen exceptions or mixing of states
between open Inspectors.

 

[Eiríkur Fannar Torfason]

Thank you Ken for taking the time to respond to my post. Invariably when I
run into an Outlook development problem and hit the internet in search of a
clues I find that you, Sue Mosher or Dmitry Streblechenko have already helped
a poor soul with the exact same problem. You've saved me a lot of grief,
especially this summer which I've spent almost exclusively working on Outlook
add-in development. I owe you a debt of gratitude.

Your assumption is correct, the tags of the UI elements do not include an
inspector-specific suffix. I'm curious as to how/where you create the UI
elements when you do so. Do you do it from the InspectorWrapper/Outlook or
from the add-in in Word? If they're created by the add-in in word, how do you
access the tag suffix?

Yours,
Eiríkur Fannar Torfason

 

[Ken Slovak - [MVP - Outlook]]

Thanks for the compliments

I get and store an int value in the wrapper class when I add it to the
Inspectors or Explorers collections/lists. I convert that to a string value
and append it to the Tag values when I create any UI in either an Inspector
or Explorer. The value is incremented for each new Inspector or Explorer, so
it's always unique for that session.

For Inspectors I create my UI in the first Activate() event. In
NewInspector() I add it to the wrapper collection if I'm handling the item.
In the wrapper initialization I set up an Inspector object as well as item
objects and set up their event handlers. Then I set a flag _setup to true
and check that in Activate(). If true I call my DoSetup() method to add UI
and whatever other initializations I need. Then if DoSetup() completes I set
_setup to false.

In NewInspector() the Inspector object reference is a weak object reference
for CurrentItem. Even something like IsWordMail() can return a false value
at that point even though it's the only editor for Outlook 2007. About all I
ever use that reference for is to test Inspector.CurrentItem.Class or
MessageClass. When Activate() fires the reference is a strong reference and
I can get every property I need, including a CommandBars collection if
needed.

I do the UI and all other processing in the Outlook addin. I don't set up a
separate Word addin. I do instantiate Word objects such as Document and
Application in my Outlook addin, so I can handle WindowActivate(). I use
that event to decide whether to show or hide my UI. If wn.Envelope.Visible
is true it's a mail item, if not it's a Word document. I can then iterate
that document's CommandBars collection looking for my UI and deal with
enabling it or setting visibility that way.

One thing to be careful of in managed code is having a class that declares
Word objects if Word isn't actually installed. Say it's an Outlook only
installation, instantiating the class that declares the Word objects will
throw an exception, so I have an InspectorBaseHandler class and then
separate InspectorHandler and InspectorWordMailHandler classes that inherit
from the base class. If Word isn't installed I then would only instantiate
the non-Word handler and avoid the exceptions.

 

[Eiríkur Fannar Torfason]

Many thanks for the detailed description. We'll try altering our approach
according to your guidelines and see if that takes care of our problem.

Cheers,
Eiríkur Fannar Torfason