tags:

views:

291

answers:

2

I have written an outlook add-in to filter spam. The issue is that when the add-in is doing its job of processing a message, and especially with a large attachment that it is procesing / reading through, it is taking a lot of time and because of this the main outlook UI is un-responsive and users cannot do anything with the UI.

Is there an asynchrounous way of running the add-in processing, so that the outlook UI remains OK.

The add-in does a lot of things dueing its procesing of each message and hence it takes a lot of time.

A: 

It's just like with any other program basically. If you need to do something outside of the main thread do so (i.e. create another thread). There's no Outlook-specific API or framework, though.

You have to be extra careful about exception handling though. Unhandled exceptions escaping from a thread can have the weirdest results (though in most cases Outlook will simply crash).

Also, if at all possible you should try to avoid or at least drastically limit accessing the Outlook Object Model from within your processing thread.

Finally, another thing you should make sure of is that you explicitly call CoInitializeEx / CoUninitialize specially for your new thread if it in any way directly or indirectly uses COM-related functions.

Oliver Giesen
yeah i understand. So i will essentially need to spawn a new Win32 thread that will process each item? i.e. this will need to happen in the COM add-in i take it?Its written in C++. Any more tips on spawing these thread please :-)Thnaks.
That's the idea, yes. Where else would you have it happen?You don't necessarily need a thread per item, though. That's totally up to you. I'm not a C++ coder myself so I couldn't give you any specifics on multi-thread programming in that language (except a vague wave towards the `CreateThread` API)
Oliver Giesen
+1  A: 

Creating another thread won't help you if the bulk of the time is being spent in the Outlook API. Due to the threading model in Outlook, accessing the object model from another thread will cause the call to be marshalled to the main thread which means now your UI is still frozen and your background thread is blocking.

If most of the work is spent doing things that don't touch the Outlook object model, you'll probably see a significant improvement spinning off a separate worker thread (or thread pool) to process the attachments you've saved.

Josh Einstein
Exactly - no matter how you distribute work to background threads, Outlook Object Model will serialize the calls back into UI thread and block :(. BTW, some Visual Studio APIs are pretty similar - once you use them more than lightly, they block the UI.I'd be happy if someone knew about workaround...
Tomáš Kafka