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.

--
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 ...
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