Problem with multiple wordmail editors in Outlook 2003

  • Thread starter Eiríkur Fannar Torfason
  • Start date
Status
Not open for further replies.
E

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?
 
K

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" <EirkurFannarTorfason
wrote in message news:1AAC2333-7AEC-40AC-A3FC-7DE15AC49CAA@microsoft.com...
> 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?
 
E

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
wrote:


> 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" <EirkurFannarTorfason
> wrote in message news:1AAC2333-7AEC-40AC-A3FC-7DE15AC49CAA@microsoft.com...
> >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?


>
 
K

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" <EirkurFannarTorfason
wrote in message news:6C0F222E-6676-4C71-B5BE-FD4A5E7EF206@microsoft.com...
> 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
 
E

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
wrote:


> 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" <EirkurFannarTorfason
> wrote in message news:6C0F222E-6676-4C71-B5BE-FD4A5E7EF206@microsoft.com...
> > 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


>
 
Status
Not open for further replies.
Similar threads
Thread starter Title Forum Replies Date
D Subject Line Problem - Multiple RE and FW Using Outlook 5
A Outlook multiple IMAP account problem Using Outlook 2
M Outlook 2010 Problem with OutLook 2010 32 bit, after Windows Auto Update Using Outlook 3
Marc2019 Outlook 2016 Font Problem Using Outlook 5
X I have met my waterloo trying to resolve embedded graphics problem with outlook 2007 and now 2016 Using Outlook 1
D Problem with custom form including _DocSiteControl1 Outlook VBA and Custom Forms 0
S Outlook 2007 Calendar instant search problem. Windows 7 Using Outlook 4
S Outlook 2007 Calendar instant search problem. Windows 7 Using Outlook 0
D Sort Problem with Sent Folders Using Outlook 1
S Conditional formatting problem with "is not empty" and categories Using Outlook 2
Mark Foley The upload of "Calendar" failed. There was a problem with the request. Using Outlook 6
avant-guvnor Import csv problem Using Outlook 7
katehawkins Outlook 2013 Ost to pst conversion problem Using Outlook 1
AbbieWhite The problem with a fairly large file. Using Outlook 3
I Outlook 2013 Send problem - 'Not Responding' forever Using Outlook.com accounts in Outlook 10
EmelineGueguen Help to understand the problem of work Using Outlook 1
W Outlook 2016 search problem persists after applying all known solutions Using Outlook 12
S problem with convert Using Outlook 1
S SendFromAccount - Problem trying to test existing value in open email Outlook VBA and Custom Forms 2
DruinaBiscardi unexpected problem in outlook Using Outlook 1
V Outlook 2003 problem with Windows 10 Creators Update 1709 Using Outlook 0
G Windows Update Causes BCM Database Access Problem? BCM (Business Contact Manager) 4
Grimev66 problem with conversion ost to pst Using Outlook 2
R Problem with searching public folders Exchange 2013/16 Exchange Server Administration 2
J Problem with Outlook 2016 new mail tray icon alert (envelope in the systems tray) Using Outlook.com accounts in Outlook 0
S Problem running Command button code Outlook VBA and Custom Forms 2
A .ost file problem Using Outlook 4
G PROBLEM REGARDING OUTLOOK STORAGE LANGUAGES Using Outlook 4
PetraTech Odd Folder View Problem Using Outlook 3
V iCloud problem Using Outlook 9
D Reply Problem with Outlook.com account Using Outlook.com accounts in Outlook 0
MattC Problem with Outlook 2007 & iCloud / duplicate tasks Using Outlook 1
V Problem moving folders Using Outlook 4
C Problem tracking meeting responses Using Outlook 3
Mark Foley Problem subscribing to shared calendar Using Outlook 1
K Problem with FreeBusy (before 1pm only) Outlook VBA and Custom Forms 7
skylark53 Advanced recurrence problem Using Outlook 2
E RSS export as OPML problem Using Outlook 4
D outlook 2013 contact list problem Using Outlook 0
T Problem with .Recipients.Add("alias") Outlook VBA and Custom Forms 3
P Problem with Outlook 2013 Attachments Using Outlook 4
E Outlook 2007: Problem with "Move to Folder >" button on toolbar Using Outlook 6
D No problem ... at this minute, just thanking you for your help. Using Outlook 1
T Random problem in VBA macro Outlook VBA and Custom Forms 6
R Outlook won't run except in Safe mode problem Using Outlook 5
J outlook 2010 delegation problem Using Outlook 3
B Problem with import Excel BCM (Business Contact Manager) 1
chupacabra Problem with IMAP .pst file Using Outlook 13
J categorize problem outlook 2010 Using Outlook 3
deonholt Address Book problem and created new profile ... Using Outlook 1

Similar threads

Top