VSTO Outlook BackgroundWorker Shutdown

[CribGoch]

Hi all

I have an Outlook addin running in Outlook 2003 + vs 2005. I use a
BackgroundWorker to do some work on a separate thread. All this works fine.

However, as soon as the user closes Outlook, the background thread (if
running) appears to freeze. The thread seems to be frozen before I get to
handle the closedown in ThisApplication_Shutdown event handler.

thread.IsBusy returns true, but when running in the debugger all
debug.Writeline output ceases, which is what leads me to think that the
thread has frozen. I have tried a loop to wait until IsBusy returns false,
but this never happens.

If I just ignore the thread and let the application close, shutdown
continues as normal, except of course that the thread has not terminated
under my control. This is unsatisfactory.

Does anyone have any ideas?

Regards
Andy

 

[Ken Slovak - [MVP - Outlook]]

Use the Explorer.Close() event to check for no remaining Explorers (last one
closing) and no open Inspectors. If that's the case then it indicates
Outlook is closing. Use that event handler to cancel your background thread.

Also, make sure your background thread is not accessing the Outlook object
model at all without marshaling the background thread to your addin's main
thread. Outlook must only be accessed on the main thread or else you'll hang
or crash Outlook.

 

[CribGoch]

Thanks for the reply.

I did try this.

However, the close event on the final explorer never seems to be received. I
did what should be necessary to handle the event on the ActiveExplorer. If I
then simply close outlook no event is raised. If I open a second explorer,
and then close what was the activeExplorer, the event is appears. This would
imply that the handler is correctly configured, but that I just never get the
event for the final explorer.

Regards, Andy

 

[Ken Slovak - [MVP - Outlook]]

I don't know how you're setting up your handler but I do get
Explorer.Close() when the last Explorer closes and I get it even if there
was only 1 Explorer open.

I use code something like this in Startup after I've initialized a class
level Explorers object:

_explorer = _outlook.Explorers[1]; // after checking for
Explorers.Count > 0

After that I add the Close handler for the Explorer.

 

[CribGoch]

Hmm, I am not sure why I am not getting that. I have put together a very
simple test and I still dont get it. Never mind, I have tried something else
that seems to work.

In the application shutdown I add a DoEvents() to the waiting loop:-

Do While m_BackgroundWorker.IsBusy
Application.DoEvents()
Loop

This seems to hurry the thread along back to its normal speed. I think I was
wrong about it freezing completely. It was probably running v e r y s l o w
l y. I dont know why the thread should need the doevents to perform.

Regards
Andy

I don't know how you're setting up your handler but I do get
Explorer.Close() when the last Explorer closes and I get it even if there
was only 1 Explorer open.

I use code something like this in Startup after I've initialized a class
level Explorers object:

_explorer = _outlook.Explorers[1]; // after checking for
Explorers.Count > 0

After that I add the Close handler for the Explorer.

Thanks for the reply.

I did try this.

However, the close event on the final explorer never seems to be received.
I
did what should be necessary to handle the event on the ActiveExplorer. If
I
then simply close outlook no event is raised. If I open a second explorer,
and then close what was the activeExplorer, the event is appears. This
would
imply that the handler is correctly configured, but that I just never get
the
event for the final explorer.

Regards, Andy

 

[Ken Slovak - [MVP - Outlook]]

DoEvents primes the Windows message pump and allows messages on other
threads to be processed. It sounds like your background thread was blocking.

 

[CribGoch]

In my test app, all it is doing is a Math calc and a Debug.Writeline(). I
suppose it is the Debug statement that needs the UI messages to be processed.
I have since tried removing the debug and it seems to run at the expected
speed without the DoEvents() on the UI thread.

Thanks for your thoughts on this.
Andy