Multithreading in Outlook

[Vladimir Chtchetkine]

Hi everybody!

Pretty much generic question How do I do my own
multithreading in Outlook? Straight forward path has
failed (just as I suspected If I create my own thread
(using SDK's _beginthreadex call) there are certain
operations that lead to disaster For instance, when I
try to get Actions on a Mail item that I just created (in
the context of the same thread) Outlook throws "Unable to
install custom action" (or something similar to that) msg
box and hangs.
I tried (in three different attempts) to call
CoInitialize, CoInitializeEx(multithreaded) OleInitialize
in the beginning of my thread execution but neither one
seemed to be able to change anything.
So, HOW DO I DO multithreading in Outlook?

TIA,

Vladimir

 

[Mark Bower [MSFT]]

Anytime you interact with the Office APIs you should always do so on the UI
thread of the Office application. Anything else could cause unpredictable
errors like the one you have.

Basically the APIs weren't designed or tested to be thread-safe, so don't go
there! Of course if you want to go spawn a background thread and do some of
you own work there, then that's fine - just switch back to the UI thread
whenever interact with the Office APIs.

--
Mark Bower
Microsoft
http://blogs.msdn.com/bowerm

This post is provided 'as-is' without warranty and confers no rights.

 

[Vladimir Chtchetkine]

Mark:

Thanks! That was something I suspected... Unfortunately,
due to the async nature of the product I'm working with
there will be some async events (generated outside
Outlook in an arbitrary thread context) in which I should
respond by changing properties of some outlook items. As
I understood, the best way for me to do it is to collect
event info (not touching any Outlook API), queue this
info, signal an Outlook UI thread and in context of this
UI thread unqueue event info and do whatever I need to do
with Outlook items. The question remains (raises) how do
I do this I mean I have no problem queuing stuff but
what thread should I signal? Or what event should I
listen to? I'll give you a real example (actual problem).
In my addin's OnStartupComplete I synchronize with some
DB and create bunch of items in some Outlook folder.
There could be just too many items and I want to do that
synchronization process in background as much as possible
(so Outlook is available for other jobs than just
synchronizing to my DB). So (obvious) solution is to fire
up a background thread. and that's where I got hurt. So,
how do I (from my background thread) trigger an Outlook
event to which I can subscribe within OnStartupComplete
handler?

TIA,

Vladimir

 

[Vladimir Chtchetkine]

Well, sort of solved. I need some comments (I mean I
would appreciate them) on the approach...
In my OnStartupComplete handler I create a (hidden)
window and whenever I need to touch outlook API from an
arbitrary thread (that I've created or my async events
use) I send a message to that window (so, I have some
messaging protocol) and in my window's message handler I
actually do what I need using Outlook API. I tested on
the problem that inspired initial post and it works just
fine. But I wander if that's THE approach I should take.
Any comments?

TIA,

Vladimir

 

[Mark Bower [MSFT]]

I think that should work just fine.

The way I have done it in the past (without resorting to Win32 API) is in
OnStartupComplete() create an instance of the Control class and instantiate
it. Call CreateControl() to initialise it fully. No hidden window is
required. Create a delegate for the method you plan to call that will
interop with the Office APIs. Then to force the thread switch call
Control.Invoke() passing the name of your delegate and your method will be
executed on the Office UI thread.

Just looking back at your original post, you don't say whether you are
working in managed code or not, so the technique may not be relevent to
you.


--
Mark Bower
Microsoft
http://blogs.msdn.com/bowerm

This post is provided 'as-is' without warranty and confers no rights.

 

[Vladimir Chtchetkine]

Mark:
Thanks for the input. I use C++ so all these beauties of delegates and so on
are not applicable in my case. But I don't mind As long as hidden window
approach is appropriate, I'm fine