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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"EirÃ*kur Fannar Torfason"
wrote in message ...
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?