Outlook, CommandBars and WordMail as Emaileditor

microsoft.public.office.developer.outlook.vba

8 May 2007 4:10 PM

stensby

Hi,

I've been stuck with the same problem for a couple of days now, so I
hope someone have a solution of my problem.

Case:
I'm writing an Outlook-addin using VSTO 2005 SE and VS2005.
I use a sort of InspectorWrapper and ExplorerWrapper so multiple
inspectors is not a problem when not using WordMail.

But when Word is used as the email-editor it seems like all inspectors
(and Word as well) uses the same CommandBars collection
(Inspector.CommandBars). I've tried to solve it by catching the
Word_WindowActivate event and use the Doc.CommandBars collection
instead but it's still the same object as when using
Inspector.CommandBars.
The result is that the CommandBarButtons I creates will be the same
reference between the different inspectors, thus the events will fire
as many times that there are inspectors.

Hope you understand my dilemma and can help me with this.

Gazza

8 May 2007 9:37 PM

Ken Slovak - [MVP - Outlook]

Outlook 2003?

First, make sure each button and toolbar you add has a unique Tag property.
That way you get one Click event and not one per Inspector.

Second, check for wn.EnvelopeVisible = true in Word_WindowActivate. That's a
WordMail window and not a Word doc. Enable and show your toolbars and
buttons appropriately.

When you enable and disable toolbars and buttons iterate the CommandBars
collection and look for CommandBar objects that are BuiltIn = false. Match
the Tag value with the key for that Inspector. Make sure you have a unique
key stored in each Inspector. If it's the correct Inspector enable and make
visible that toolbar. If it's not make it invisible and disabled.

I use a string unique to that addin plus the Inspector key value to create a
unique Tag value. Then I check for the string to see if I created the
toolbar and the string + key to see if it's for that Inspector.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm

<sten***@gmail.com> wrote in message

Show quote

news:1178640649.715352.273770@y80g2000hsf.googlegroups.com...
> Hi,
>
> I've been stuck with the same problem for a couple of days now, so I
> hope someone have a solution of my problem.
>
> Case:
> I'm writing an Outlook-addin using VSTO 2005 SE and VS2005.
> I use a sort of InspectorWrapper and ExplorerWrapper so multiple
> inspectors is not a problem when not using WordMail.
>
> But when Word is used as the email-editor it seems like all inspectors
> (and Word as well) uses the same CommandBars collection
> (Inspector.CommandBars). I've tried to solve it by catching the
> Word_WindowActivate event and use the Doc.CommandBars collection
> instead but it's still the same object as when using
> Inspector.CommandBars.
> The result is that the CommandBarButtons I creates will be the same
> reference between the different inspectors, thus the events will fire
> as many times that there are inspectors.
>
> Hope you understand my dilemma and can help me with this.
>
> Gazza
>

9 May 2007 7:50 AM

stensby

Thank you Ken for the quick reply!

Outlook version is 2003 by the way.

Let's see if I have understood your recommendations (I've used your
excellent InspectorWrapper, is there a possability that you could
submit an example of the InspectorWrapper with full WordMail
support?):

First:
I'm using unique Tags for my buttons but I can't find a Tag property
for the CommandBar object, is there such a property?

Second:
In the Word_WindowActivate event I allready check for
wn.EnvelopeVisible.
But thank you for confirming that I should do that.
I've read an earlier post you've made (http://www.tech-archive.net/
Archive/Office/microsoft.public.office.developer.outlook.vba/2005-12/
msg00074.html)
regarding WordMail. In that post you delete existing toolbars in
Word_WindowActivate instead of making the unvisible/disabled.
I've tried to delete them also but since it seems like all inspectors
and the Word application shares the same CommandBars object my
toolbars will be deleted in all inspectors as well, not only in Word.
Does all inspectors and Word application shares the same CommandBars
object?

I will go on and implement the solution with disabling the toolbars as
you suggested.
Thank you for taking time and answer my questions.

Gazza

Show quote

On 8 May, 23:37, "Ken Slovak - [MVP - Outlook]" <kenslo***@mvps.org>
wrote:
> Outlook 2003?
>
> First, make sure each button and toolbar you add has a unique Tag property.
> That way you get one Click event and not one per Inspector.
>
> Second, check for wn.EnvelopeVisible = true in Word_WindowActivate. That's a
> WordMail window and not a Word doc. Enable and show your toolbars and
> buttons appropriately.
>
> When you enable and disable toolbars and buttons iterate the CommandBars
> collection and look for CommandBar objects that are BuiltIn = false. Match
> the Tag value with the key for that Inspector. Make sure you have a unique
> key stored in each Inspector. If it's the correct Inspector enable and make
> visible that toolbar. If it's not make it invisible and disabled.
>
> I use a string unique to that addin plus the Inspector key value to create a
> unique Tag value. Then I check for the string to see if I created the
> toolbar and the string + key to see if it's for that Inspector.
>
> --
> Ken Slovak
> [MVP - Outlook]http://www.slovaktech.com
> Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
> Reminder Manager, Extended Reminders, Attachment Optionshttp://www.slovaktech.com/products.htm
>
> <sten***@gmail.com> wrote in message
>
> news:1178640649.715352.273770@y80g2000hsf.googlegroups.com...
>
>
>
> > Hi,
>
> > I've been stuck with the same problem for a couple of days now, so I
> > hope someone have a solution of my problem.
>
> > Case:
> > I'm writing an Outlook-addin using VSTO 2005 SE and VS2005.
> > I use a sort of InspectorWrapper and ExplorerWrapper so multiple
> > inspectors is not a problem when not using WordMail.
>
> > But when Word is used as the email-editor it seems like all inspectors
> > (and Word as well) uses the same CommandBars collection
> > (Inspector.CommandBars). I've tried to solve it by catching the
> > Word_WindowActivate event and use the Doc.CommandBars collection
> > instead but it's still the same object as when using
> > Inspector.CommandBars.
> > The result is that the CommandBarButtons I creates will be the same
> > reference between the different inspectors, thus the events will fire
> > as many times that there are inspectors.
>
> > Hope you understand my dilemma and can help me with this.
>
> > Gazza- Hide quoted text -
>
> - Show quoted text -

9 May 2007 6:12 PM

Ken Slovak - [MVP - Outlook]

Most of my WordMail stuff is proprietary, although I've mentioned most of
what I do in posts I've made. What you have it the main components of what I
do, all that's really missing is getting the hWnd for the Inspectors
(WordMail and Outlook editor) for various uses.

CommandBar doesn't have a Tag property so I stuff the unique string + key
value in the Name property.

I no longer delete the other toolbars, I just make them disabled and
invisible.

Also, when I make any change to a toolbar or button at all (visibility or
enabled state or icons or whatever) I set Word.CustomizationContext.Saved =
true. That lets me make changes and not prompt for saving changes to
normal.dot or whatever. I no longer try to maintain my own
CustomizationContext, it tends to interfere with any other addins. Now I
just use whatever's set by whatever else is running in Word.

The other thing with Word CommandBar objects is that they are there but
almost every time I reference them I re-instantiate them. For example, in a
button Click event if I want to change the icon (say the button is a toggle
and I have an image for each state). If I try to do that in Click I get an
automation error. If I re-instantiate the button object there I can do what
I want. Same thing even when setting one button enabled or disabled, I end
up having to re-instantiate it for every access even with class level object
variables holding the reference. Weird, but so many things are weird with
WordMail.

Show quote

news:1178697001.216483.223830@n59g2000hsh.googlegroups.com...
> Thank you Ken for the quick reply!
>
> Outlook version is 2003 by the way.
>
> Let's see if I have understood your recommendations (I've used your
> excellent InspectorWrapper, is there a possability that you could
> submit an example of the InspectorWrapper with full WordMail
> support?):
>
> First:
> I'm using unique Tags for my buttons but I can't find a Tag property
> for the CommandBar object, is there such a property?
>
> Second:
> In the Word_WindowActivate event I allready check for
> wn.EnvelopeVisible.
> But thank you for confirming that I should do that.
> I've read an earlier post you've made (http://www.tech-archive.net/
> Archive/Office/microsoft.public.office.developer.outlook.vba/2005-12/
> msg00074.html)
> regarding WordMail. In that post you delete existing toolbars in
> Word_WindowActivate instead of making the unvisible/disabled.
> I've tried to delete them also but since it seems like all inspectors
> and the Word application shares the same CommandBars object my
> toolbars will be deleted in all inspectors as well, not only in Word.
> Does all inspectors and Word application shares the same CommandBars
> object?
>
> I will go on and implement the solution with disabling the toolbars as
> you suggested.
> Thank you for taking time and answer my questions.
>
> Gazza

10 May 2007 12:38 AM

stensby

Thank you for your excellent answers Ken.

I've successfully implemented support for WordMail thanks to you.

I suspect you use hWnd to make Messageboxes and Windows Forms show up
in front of inspectors.

Now I have one little problem left:
When the Outlook process is terminated from the Task Manager for
example, neither ThisAddin_Shutdown or inspectors Close event will
fire. So there's no event to delete toolbars in.
The result is when Outlook is opened again there will be "old"
toolbars from the last Outlook sessions in my inspectors.
Do you have a solution of this?

I have a lot of other questions regarding development of outlook
addins using VSTO 2005 SE:
- Where should error handling be implemented? Outlook seems to just
swollow COM exceptions.
Do I have to implement error handling in every public function and
event?
- Which strategy should I use regarding Marshal.ReleaseComObject? In
some situations it seems necessary to release COM-objects to avoid
"cached" values in MailItems, Appointments etc. In other situations I
cannot release them because of mysterious errors that will appear. I
cannot find any examples of errorhandling or Marshal.ReleaseComObject
in the Starter Kits and Samples that Microsoft provides...

Maybe the above questions should be in new threads instead.

Thank you for all your help Ken.

Gazza

10 May 2007 2:20 PM

Ken Slovak - [MVP - Outlook]

Yes, I mostly use hWnd to control the z-order of dialogs and such that I
want to display over an Inspector. I also use it for a few other things, but
mostly for z-order.

First of all, using Task Manager to kill Outlook is not generally a good
idea. It cause problems in some cases. That said, I do get
ThisAddin_Shutdown() when Outlook is closed that way. I also get
Explorer.Close although Inspector.Close doesn't fire.

In cases where I don't use VSTO but use a shared addin I get these events in
this order:
    Explorer.Close
    BeginShutdown
    OnDisconnection

If you aren't getting ThisAddin_Shutdown() something is wrong. However, in
Explorer.Close you always can check for Explorers.Count and
Inspectors.Count.

I use a lot more error handling in my managed code addins than in my
unmanaged code addins. I use try...catch blocks everywhere. In many cases I
have lots of nested try...catch blocks. Where any error can occur for any
reason I use try...catch.

Using Marshal.ReleaseComObject and calling GC is a balancing act. It
definitely releases object references on demand versus an indeterminate
period before the garbage collector runs on its own, but it impacts speed.

In general I just set object references to null if I don't need them any
longer and I have no immediate need to reference that object again. In
critical paths I use Marshal and then call for GC.Collect and
GC.WaitForPendingFinalizers. Mostly I just do that for the module level
objects declared in ThisAddin, if at all. I've found that VSTO 2005 SE is
pretty good on its own about releasing things so Outlook can close.

If you look at the addin samples from the Outlook team they do use Marshal
and calls to GC in some cases, even in the VSTO samples.

Show quote

news:1178757503.989821.130310@q75g2000hsh.googlegroups.com...
> Thank you for your excellent answers Ken.
>
> I've successfully implemented support for WordMail thanks to you.
>
> I suspect you use hWnd to make Messageboxes and Windows Forms show up
> in front of inspectors.
>
> Now I have one little problem left:
> When the Outlook process is terminated from the Task Manager for
> example, neither ThisAddin_Shutdown or inspectors Close event will
> fire. So there's no event to delete toolbars in.
> The result is when Outlook is opened again there will be "old"
> toolbars from the last Outlook sessions in my inspectors.
> Do you have a solution of this?
>
> I have a lot of other questions regarding development of outlook
> addins using VSTO 2005 SE:
> - Where should error handling be implemented? Outlook seems to just
> swollow COM exceptions.
> Do I have to implement error handling in every public function and
> event?
> - Which strategy should I use regarding Marshal.ReleaseComObject? In
> some situations it seems necessary to release COM-objects to avoid
> "cached" values in MailItems, Appointments etc. In other situations I
> cannot release them because of mysterious errors that will appear. I
> cannot find any examples of errorhandling or Marshal.ReleaseComObject
> in the Starter Kits and Samples that Microsoft provides...
>
> Maybe the above questions should be in new threads instead.
>
> Thank you for all your help Ken.
>
> Gazza
>