Balu526 on Fri, 16 Dec 2016 12:45:36
I am trying to create a plugin for Outlook 2010,
So I am trying to achieve this by multithreading(multi processes),
Please suggest what is the scope of multithreading in Outlook 2010 and how much its safe and also the best practices regarding multithreading in Outlook 2010.
Thanks In Adv
RLWA32 on Fri, 16 Dec 2016 13:25:28
COM add-ins must use the STA (Single Threaded Apartment) model. You can use multiple threads in your add-in but the Outlook Object Model's interfaces must only be called from Outlook's UI thread.
Balu526 on Fri, 16 Dec 2016 13:43:09
Thanks For your reply,
another small question - Not responding outlook when another process running. is there any solution for that ??
Thanks in Adv
RLWA32 on Fri, 16 Dec 2016 14:13:02
another small question - Not responding outlook when another process running. is there any solution for that ??I don't understand what you are asking. What other process? What does that have to do with Outlook? Can you clarify?
Dmitry Streblechenko _MVP_ on Fri, 16 Dec 2016 15:40:04
Multithreading within a single process is very different from spawning additional processes.
Outlook is single threaded when it comes to using the Outlook Object Model - secondary threads can sometimes work in older versions of Outlook (such as Outlook 2010), but that can and does cause unpredictable crashes at the worst possible moment. Newest versions of Outlook (2016) raise an exception immediately as soon as access to the Outlook Object Model is detected on a thread other than the main one.
Using separate process won't help either - all out-of-proc calls to OOM will be marshalled back to the main Outlook thread.
The only way to use multithreading in Outlook is
1. Avoid touching any UI elements (Ribbon etc.) on a separate thread
2. Do not touch Outlook Object Model on a secondary thread.
3. If you still need to process Outlook data (messages, folders, address book objects, etc.) on a secondary thread, Extended MAPI (C++ or Delphi only) or Redemption (wraps Extended MAPI and can be used from any language) is the only way. Extended MAPI is designed to be used from multiple threads. If you are using Redemption, save the value of the Namespace.MAPIOBJECT property (it returns IMAPISession Extended MAPI object) on the primary thread; on the secondary thread, create a new instance of the RDOSession object (it roughly corresponds to the Namespace object in OOM) and set the RDOSesion.MAPIOBJECT property to the value saved on the primary thread. You will need to be careful to make sure all object created/retrieved on that secondary thread are released on that thread (instead of being auto released by the Garbage Collector in .Net - MAPI objects have thread affinity) - that means avoiding multiple dot notation and releasing all objects using Marshal.ReleaseComObject.
RLWA32 on Fri, 16 Dec 2016 17:21:08
In the event that you do decide to use Extended MAPI from multiple threads (C++ or Delphi) you should be aware of https://blogs.msdn.microsoft.com/stephen_griffin/2004/09/24/mapi-multithreading-rules/ and also https://blogs.msdn.microsoft.com/stephen_griffin/2009/05/22/the-fifth-mapi-multithreading-rule/
Although Outlook will have initialized MAPI before an add-in loads it is good to be aware of them since, for example, it is still necessary for separate threads (C++ or Delphi) to call MAPIInitialize/MAPIUninitialize.
Dmitry Streblechenko _MVP_ on Fri, 16 Dec 2016 18:17:48
And with Outlook 2016 and its virtualization features, the rules are enforced a lot stricter...