Hi,

It sounds like you might benefit from reviewing the COM threading documentation which can be found here: http://windowssdk.msdn.microsoft.com/en-us/library/ms693344.aspx. Hopefully, that will fill in any of the gaps in your reading of other threads.

It is possible to do multi-threading in VSTO solutions regardless of whether your threads interact with the Office OM. However, in the latter case, you need to implement IMessageFilter (the COM version, not System.Windows.Forms version) and you need to understand that all calls into the Office OM will be serialized so while one thread is calling into Office, the remaining threads would be blocked from doing so.

All of this is because the Office object model isn't thread safe. Since COM can't control the fact that a client might try to call a non-thread safe server with multiple threads, it does the next best thing which is to serialize the calls. On the other hand, if you are calling into a component that is thread-safe, then COM doesn't need to get in the way and concurrency is allowed.

As I said, it is always possible to use multiple threads in VSTO. The issue that you need to understand is how much time your threads will spend being blocked and whether that will invalidate the performance gain you are hoping for. If your tasks are truly self-contained (or call into Free Threaded components) then you won't blocked by COM if you run them on background threads.

Sincerely,

Geoff Darst

Microsoft VSTO Team

Geoff,

That was very helpful and i have been able to test some multi threading in VSTO code too. I also was able to see how Office objects reject calls from outside threads if they are busy themself. I did that by starting to edit some cell right when my code made a COM call. To be able to handle this problem gracefully i guess i will need to implement the IMessageFilter interface as you mentioned.

I am a bit confused on what code i need to add in the preFilterMessage method and whats it purpose. And then i guess i also have to implement the RetryRejectedCall method as i want to try calling the COM again until my call gets lucky and excel is able to respond. Can you please post some sample code as i was unable to find it elsewhere in the VSTO perspective of things? Either VB.NET or C# is fine. There is no such code at all in the entire forum and i am sure many people will find it useful.

If all this goes through successfully i am sure i will be able to convince my manager to start using VSTO as compared to the VBA we do right now.

Thanks!!

Hi,

The Windows Forms team did the world no favors when they reused the IMessageFilter name for their interface. System.Windows.Forms.IMessageFilter is a way to hook the message pump for a Windows Forms application; it has nothing to do with the COM IMessageFilter. What you actually need to do is the following:

1. Implement the COM version of IMessageFilter: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/7e31b518-ef4f-4bdd-b5c7-e1b16383a5be.asp. Since this is a native interface, you will need to create the runtime callable wrapper for this yourself. The only method that you actually need to implement is RetryRejectedCall. The other methods apply only if you are functioning as a COM server (which your thread will not be). You can just throw a NotImplementedException for those methods. The typical implementation of RetryRejected call would be to retry the call if less than some amount of time has elapsed; otherwise show the OLEUIBUSY dialog by calling OleUIBusy.

2. Register your IMessageFilter for the thread by calling CoRegisterMessageFilter. This (as well as OleUIBusy) are Win32 calls and you will need to construct your own P/Invoke declarations.

I'm sorry that I don't have a sample to offer you. Unfortunately, this isn't something I have the time to put together right now--perhaps someone else on the forum has some code to share.

Sincerely,

Geoff Darst

Microsoft VSTO Team

A good place to discuss this (and search for past posts on the topic) would be the Interop newsgroup:

http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.dotnet.framework.interop&lang=en&cr=US

Currently, there are no "interop" forums, but I understand some are planned :-) But for the moment there's only this newsgroup, with a pretty good "base".

Currently, there are no "interop" forums, but I understand some are planned :-)

<g>

That is when there will be an agreement for the definition of "interop". Is it the "interop" used as in this context, or in the context of iteroperability between all kinds of "systems" ?

Let's wait and see, for now the "interop" newsgroup is ok in this context I guess ... ;-D

-= Maarten =-