Thanks for the ideas, Ken!
Inspector.Close() - raises error, but posting WM_CLOSE to the window work's
fine!
Nevetheless it seems to be not extremely brilliant solution because it looks
like hiding the bug, but not fixing, but i guess we have no coise =)

But it works and that's greate!! Thank you once again for participating and
clarifying the problem, I appreciate it much!

I'm now interested, is there any way to describe this bug and refer to
outlook developer team, so they can fix it in future versions or future SP,
or am I very naive with this and nobody takes such misstakes into
consideration?..

"Ken Slovak - [MVP - Outlook]" wrote:

The samples on my Web site are from my book. As with any samples like that
they don't cover every single possible use case. In this case I would not
use VSTO or I'd structure things to purposely not provide UI if a use case
was discovered that wasn't good with VSTO.

For example, I might add code to disable providing ribbon UI if
Explorers.Count == 0 so that Simple MAPI Inspectors wouldn't get ribbon UI
unless an Explorer was showing. Or I might just disconnect my addin if I
discovered that case.

Another thing to bear in mind is when Startup is going to fire for you in a
VSTO addin. Internally VSTO is handling the extensibility events but waits
until OnStartupComplete() to fire the VSTO startup event.

What you are describing is what I call a "ghost Inspector". In many cases if
you do any processing at all on an item you will get that Inspector that
hangs around after it should be closed and that doesn't respond to code. One
case where that happens is if you do things in item.Send(), for example.
What I do in cases where those ghosts might appear, and Simple MAPI
Inspectors are the worst for that, is to make sure the window gets closed by
forcing it.

In the last event I'm working with for that item, say Send(), I'll
instantiate and start a timer when I'm ready to let the event finish. I
usually use 100 mS to allow time for WordMail to finish autoformatting an
item if necessary. In the timer handler I call the Inspector.Close() method.
That forces the window to be closed.

In some cases I've actually had to force the window closed by getting the
window hWnd using the Win32 API FindWindow() call and then posting a
WM_CLOSE message to the window, but that's a last ditch thing that I only
use where necessary.