Microsoft Add In button in Outlook???

[Brian]

Hello,

I have an Office XP COM Add In written in VB6 that displays a button for
each document opened in Word. The problem is that if I setup Outlook to use
Word as the email editor, I also "occasionally" see that the Add In's button
shows up on new email messages that I am composing too.

How can I check to be sure that my AddIn isn't loading for Word email
messages?

-Brian

 

[Ken Slovak - [MVP - Outlook]]

Check for Window.EnvelopeVisible = True. I usually do it in the
WindowActivate event. If True it's a mail window.

 

[Brian]

Thanks Ken. I will try that out. I will likely check check the Word
Application's ActiveWindow's EnvelopeVisible property (i.e.
objApp.ActiveWindow.EnvelopeVisible). Of course checking to make sure that
the Application's ActiveWindow Is NOT Nothing!

You have been so helpful to me in constructing my addins, I was wondering if
you might be able to answer one more question for me...

If I have a CommandBarButton that displays some text, and this text could be
different for each open Word document (depending on a value stored in a
Custom Document Property for each Document), is it appropriate to completely
DESTROY and RECREATE the CommandBarButton on the Word application's
Document_Change event???

I have been noticing that under the following scenario I seem to be loosing
a reference to my CommandBarButton when created only one time during the
Addin initialization (IDTExtensibility2_OnConnection) event?

1. After fresh reboot of machine, Start up Word for the first time. This
fires the IDTExtensibility2_OnConnection event which in turn executes code
to initialize Word Addin, and create CommandBarButton.

2.After Word has opened (and the default "new" document displayed), launch
Outlook (with Outlook configured as my email editor).

3. After Outlook launches, click the button in Outlook to create a new Mail
Message.

4. Close down originally opened Word instance (Document and Word Window).

5. Close down the Outlook Mail Message.

6. Open Word again (Start > Programs > Microsoft Word).

7. Now my addin didn't get reloaded, but I no longer have a reference to my
originally created CommandBarButton. I have verified that none of my code
to clean up the button has been executed. Not sure why it lost it's
reference, but my guess is that it has something to do with the way Word
handles object references or loaded DLLs when running initially, then
running through Outlook. Any thoughts???????

Thanks again so much!!! Is there anything I can nominate you for to
recognize your ability and willingness to help out the folks who come to
this newsgroup???

If you ever need a hand doing some .NET 2.0 WinForms or ASP.NET development,
please let me know!!! I owe you one....or ten!!

-Brian

 

[Brian]

Window.EnvelopeVisible = True appears to work great!

Thanks again!!

-Brian

 

[Ken Slovak - [MVP - Outlook]]

I've found that with WordMail that I have to re-instantiate my
button/toolbar/menu objects each time I want to access their properties,
otherwise I get weird automation errors or errors that the property/method
doesn't exist for that object. Even in a Click event for a button, if I want
to change button.State or some other property like that or alter the image
for the button I get that error in Click. So I've gotten in the habit of
just getting a fresh reference each time I want to access a property even
those like Enabled or Visible.

With Word itself I have less experience, although I've done some Word addins
and some that have to co-exist with Outlook addins. I use the DocumentOpen
event to let me know a new Document was opened and to add UI for that. I
release the UI I created in DocumentBeforeClose and double-check that all UI
is released in OnDisconnection.

I've also found that unlike UI added to an Outlook Explorer or an Outlook
editor Inspector that Word doesn't really honor the Temporary = true
argument, that UI persists wherever it was created in the
CustomizationContext for Word. So I set CustomizationContext.Saved = true
after each time I change, add or remove something in the UI, even just a
visibility or enabled change.

I also use a technique of creating a unique Tag property for each piece of
UI that I create. I use an app specific GUID concatenated with a string
specific to that UI piece ("button1") plus a Key value for that
Inspector/Explorer. The Key is incremented for each call so it's unique for
that session.

I then check the Tags of each object I find when I iterate the
Inspector.CommandBars collection looking for UI that isn't BuiltIn = true.
If it has a partial match (GUID + UI piece are equal but Key is different) I
set that CommandBar invisible and disabled so it's not visible either in the
WordMail item or any open Word docs. I do that in WindowActivate. That way I
can manage UI for multiple open Inspectors and documents and only the
appropriate UI shows up in each and each can have a unique set of settings
without affecting any other.

As far as thanks or some nomination for something, I've been recognized as
an Outlook MVP, which is honor enough for me. I learn as much as I help in
the newsgroups, so that and the satisfaction of helping out are enough

 

[Brian]

Ken,

Thanks so much for assistance! I have actually opened up a support incident
with Microsoft on this to get their input/guidance as there isn't much good
documentation out there. Here are a few notes so far, I will reply to this
group with anything else I find out later.

* They are telling me that using the ActiveDocument property on the Word
application is not really a good thing to do. Something about
ActiveDocument may not give you what you are looking for all the time
(sounds to me that ActiveDocument implementation is buggy). You should be
very specific about the document you want to use, such as the one passed in
WindowActivate event. This is consistent with what I have experienced.

* They are also telling me that each Document object has a CommandBars
collection. It is in this collection that I should (or shouldn't) be adding
my button. This way each document controls it's own UI elements. I
expressed concern over potential overhead for this. The rep did not seem to
be too concerned with it.

* He is actually going to be providing a stub solution - a sort of shell for
how to handle the events and objects correctly. If he does, and it works, I
will be sure to somehow make the code available. My guess is that although
I am working in Office XP, it will be (somewhat) applicable to later
versions.

There is so little in the way of good documentation on this stuff. Ken,
yYou should think of writing some articles or books. Based on the amount of
postings in this group you have answered, I am sure it would be a hot
seller!

-Brian