Hello Josh,

I'm affraid, your solution isn't exactly what I need, because it deffers
my event handling, not the event itself. When I leave Inspector_Close() after
calling BeginInvoke(), Outlook will destroy the Inspector's objects. And
when my finalizing code (the other branch in Inspector_Close()) is finally
starts executing, I'll still have the same problem that I had before supressing
WM_CLOSE - COM wrapper exceptions.

Am I wrong?

WBR,
Sergey Anchipolevsky

If you have a reference to any .NET form or control you can use
BeginInvoke to "defer" the event until the next time the loop is
pumped. For example:

private bool _activating = false;

private void Inspector_Activate() {
{
try {
_activating = true;
// do stuff which might pump the loop
} // try
finally {
_activating = false;
} // finally
} // function
private void Inspector_Close() {
if ( _activating ) {
myControl.BeginInvoke(new MethodInvoker(Inspector_Close));
return;
} // if
else{
// Proceed normally
} // else
} // function
"Sergey Anchipolevsky" wrote in message
.com...

Hello Dmitry,

If your code in the Activate event handler does anything that can
potentially run the Windows message loop (such sa displaying a
message box or any other window), then Close event can potentially
fire while Activate is still beign processed. What do you do in the
Activate event handler?

I followed Josh's advice and found out that the message loop is
pumped in
CommandBars.GetEnumerator(). (very surprising actually).
I use this method to iterate through toolbar buttons and menu items
in
order to hide some of them upon inspector activation.
I implemented the following workaround that seems to work quite well.

I subclassed the inspector's window with the code that suppresses
WM_CLOSE message when it comes while the Activate handler is running.
In the end of the Activate method I explicitly call Inspector.Close()
if WM_CLOSE message has been received.

What do you think about this solution?

WBR,
Sergey Anchipolevsky