Word Mail and Office Command Bars

[tdk]

Dear Group

I have created a new command bar for Word as a VB6 COM addin. In
summary I add an entry to HKEY_CURRENT_USER\Software\Microsoft\Office
\Word\Addins and register my dll. The dll has a sink for the
AddinInstance_OnConnection() event where I create my toolbar like
this...

-----
Set cbBar = oXL.CommandBars.Add(Name:=sToolbarName, Temporary:=False)

cbBar.Position = Registry.RegGetToolbarPosition()
cbBar.Left = Registry.RegGetToolbarLeft()
cbBar.Top = Registry.RegGetToolbarTop()
cbBar.RowIndex = Registry.RegGetToolbarRowIndex()
---
Where oXL is an Application object. I set my toobar position from
registry values and save these vaules to the registry on exit so that
my toolbar can remember its position. One other thing I do is
manipulate the Application.CustomizationContext.Saved so that word
does not write any customisations to Normal.dot.

This all works fantastically well for Word!

Now enter Outlook and using Word as the mail editor. If I start
Outlook before any instances of Word and compose a message (where word
is set to my editor) it all seems to start well. An instance of
Winword.exe starts up and my toolbar loads and positions itself.

If I now start a copy of word it uses the same process Winword.exe
started by Outlook to open word but my toolbar has gone! I don't get a
call into AddinInstance_OnConnection() in these instances. I can
however right click on the toolbar area and get back my command bar
but it apears floating.

It is as though the command bar is started in word mail (WordMail=word
running from outlook) in a way that is incompatible with subsequent
word windows so it doesn't display by default.

I have managed to recognise when the first OnConnection is from
WordMail by looking at the title of the parent of the active window
(not very clean) but knowing we are starting in Outlook doesn't help
me.

Is there a way to
1) Force Word to use a new instance of winword.exe from WordMail.
2) Make the positioning compatible for toolbars started in WordMail or
not WordMail.
3) Not show my toolbar in WordMail and thus prevent it from getting
bad positioning. Simple setting .Visible=False doesn't work it just
hides the toolbar in all instances.
4) Some sort of further macro in word that can be made to bring the
toolbar back when it has been corrupted by WordMail. I assume this
would have to be added to a users Normal.dot - not something I really
want to do but if forced into it I could.

I have also played around with Temporary:=False but it seems to have
little or no affect.

I should note I've been testing on Office 2003 and Office 2000 same
problem in both. Also I've seen this behaviour in other products for
example the SnagIt toolbar so I don't think I'm alone.

It doesn't sound like a big deal but often users open their email
first thing in the morning and leave that open most of the day. Thus
any word docs they open hide my toolbar.

I hope this is enough information - seems like a fairly common problem
- would be great to get it sorted.

 

[Ken Slovak - [MVP - Outlook]]

WordMail (except for Outlook 2007) uses a subclassing of Word.exe. There's
no way to change that and it leads to some interesting problems. There's
also no way to force any different instances of Word other than what you
get.

The way you are adding the UI precludes it from working well with Outlook
since WordMail uses a different default template. And for Outlook you always
want to add UI in code and set Temporary = true.

It's usually best to handle Word and Outlook using different addins due to
the different requirements of shutting down the addin to let the parent
application close correctly. This is not the case for example for
Word/Excel/PPT addins, which can be handled using one DLL.

When Window.Activate fires you can check for wn.EnvelopeVisible = true. If
that test passes it's a WordMail Inspector that was activated, if false it's
a Word doc. Use that event to determine when to set your Outlook UI to
Visible = false/true and Enabled = false/true.

In all cases with WordMail you should add UI if you do using the
Inspector.CommandBars collection and not rely on or use anything created
another way. You still do need to handle CustomizationContext however.

The WordMail window is always "OpusApp", just as a Word doc is. The
difference is that for a WordMail window there's a child window named "_WwG"
for Outlook 2003 and earlier and "_WwF" for Outlook 2007 as a child window
of "OpusApp".

One further thing is the lack of persistence of instantiated UI. When you
want to make it invisible you most likely will receive automation errors
about the property not being available or something. When you find your UI
after Window.Activate I recommend re-instantiating the buttons and such
using the unique Tag properties you created so you can find and re-set the
button objects. Then you can call to change visibility or enabled without
errors.