Opening WinForm in Outlook 2003 VSTO Addin with Wordmail enabled

  • Thread starter Thread starter zrider350
  • Start date Start date
Z

zrider350

I have been banging my head with this issues for sometime now. Can someone
PLEASE help??? When I create a commandbar on a new inspector window that uses
word mail, the form that opens doesn't fully load. I have done a lot of
research on this and I believe it is a threading issue because I create my
command bar in word which is subclassed into Outlook. When wordmail isn't
enabled the apartment state of the executing thread is STA and when wordmail
is enabled it is MTA. I have tried to use a delegate to instantiate the form
instead with no success. Below are a couple of relevant posts I have found.
Ken Slovak mentions in one of these that he used several API calls to make
this work. Can someone please provide a working sample. If you need a sample
to reproduce I can provide one. I used the code sample to load wordmail
toolbars on the inspector_activate event. I added another windows project and
then tried to instantiate the form from my class. It never fully loads. Below
are some links I have found helpful.

http://www.eggheadcafe.com/conversation.aspx?messageid=30318020&threadid=30318015

http://social.msdn.microsoft.com/forums/en-US/vsto/thread/648a2c92-5690-4dc0-bfc0-57545abd721b/
 
Andrew's post is more relevant to what you're talking about in cases of
managed code, what I was posting about relates mostly to working with VB6
code.

For managed code you have to do thread context synchronization callbacks.
What you do is on NewExplorer() and NewInspector() event handlers you call
Windows.Forms.Application.DoEvents() to prime the message pump and then you
get the current thread context, which in that case is the context of the
main Outlook addin thread. You store that context so it's always available.

Then when you want to open a form you set up a callback to a procedure that
will run in the main thread context and pass your form name along to that
callback.

// In a class context where it will stay alive:
private static System.Threading.SynchronizationContext _syncContext = null;

In the main thread event handlers code something like this:
if (_syncContext == null)
{
System.Windows.Forms.Application.DoEvents();
if (System.Threading.SynchronizationContext.Current != null)
{
_syncContext = System.Threading.SynchronizationContext.Current;
}
}

Then when you want to show the form:

// whatever arguments you want to pass to the callback are added here
object[] args = { };

System.Threading.SendOrPostCallback callback =
new
System.Threading.SendOrPostCallback(callbackClass.callbackProcedure);

if (callback != null)
{
System.Threading.SynchronizationContext context = Globals.SyncContext;
if (context != null)
{
context.Send(callback, args);
}

In this case Globals.SyncContext accesses the stored context.

callbackClass is where the callback function lives and it's named
callbackProcedure. That procedure is what displays the form and populates
any controls from the arguments passed to it. In that callback the argumens
are passed as (Object state) and are decoded there as follows:

object[] arguments = (object[])state;

Then that array has all the arguments passed to the callback.

Note that this is not necessary for Outlook 2007, only for WordMail in
earlier versions of Outlook.
 
Back
Top