Outlook 2007 Add-in strange load behavior

[SomewhereSomehow]

Hello all!
I'm experiencing some problems with outlook add-in loading if outlook was
loaded by means of Excel, Word and so on.
Here is what i'm doing:

1) Create an empty Outlook Add-in project using Visual Studio 2008, new
Project -> Visual C# -> Office -> 2007 ->

Outlook 2007 Addin
2) Into the start up method add the following

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
System.IO.StreamWriter sw = new
System.IO.StreamWriter("c:\\AddinTest.txt");
sw.WriteLine("");
sw.Close();
}
3) Run the project. Outlook starts. See that file was created on c:
4) delete file
5) Run Outlook as it self (not from debugger) and see c:, file was created
again. Delete it.
6) Run Excel 2007, then in office menu select Send, as email. Outlook new
message form is shown, new excel work

book is packed as an attach to this letter. Look at c:. NO file was created!!!
7) press CRTL+SHIFT+ESC, to start task manager, to be sure that outlook was
started. Yes you can see process

OUTLOOK.EXE in the list.
8) Still no file.
9) Close new message window, wait for 1-2 sec.
10) Look at the c:! What a surprise! here is our file!

1) So, my first question is, why it has so weird behavior?
2) And the second onr is how to avoid this problem?

Because in my real addin, I need to customise ribbon (add one combobox) when
the new message is created and

everything is fine, if I do it directly from the Outlook (or outlook is
started and i'm doing it from excel), but

it fails if Excel starts Outlook by it's own

And another one problem is detected!
Only If the ribbon is added to project.

if i open outlook first, then excel (add-in starts ok) and try to send email
from excel - the message window stays on the screen.
And it is interesting that all controls and ribbons are available and the
content box look's like in a hung state, no redrawing. Pressing a croos to
close window closes it without any arror.
Also if I just create new message from excel, and then try to close it, it
still remains on the screen (as in send case). Pressing Close once again -
closes window.
This is completely strange!
Any one may take an experiment just add Ribbon to the project, with no user
code.
I also tried to download a Hello all!
I'm experiencing some problems with outlook add-in loading if outlook was
loaded by means of Excel, Word and so on.
Here is what i'm doing:

1) Create an empty Outlook Add-in project using Visual Studio 2008, new
Project -> Visual C# -> Office -> 2007 ->

Outlook 2007 Addin
2) Into the start up method add the following

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
System.IO.StreamWriter sw = new
System.IO.StreamWriter("c:\\AddinTest.txt");
sw.WriteLine("");
sw.Close();
}
3) Run the project. Outlook starts. See that file was created on c:
4) delete file
5) Run Outlook as it self (not from debugger) and see c:, file was created
again. Delete it.
6) Run Excel 2007, then in office menu select Send, as email. Outlook new
message form is shown, new excel work

book is packed as an attach to this letter. Look at c:. NO file was created!!!
7) press CRTL+SHIFT+ESC, to start task manager, to be sure that outlook was
started. Yes you can see process

OUTLOOK.EXE in the list.
8) Still no file.
9) Close new message window, wait for 1-2 sec.
10) Look at the c:! What a surprise! here is our file!

1) So, my first question is, why it has so weird behavior?
2) And the second onr is how to avoid this problem?

Because in my real addin, I need to customise ribbon (add one combobox) when
the new message is created and

everything is fine, if I do it directly from the Outlook (or outlook is
started and i'm doing it from excel), but

it fails if Excel starts Outlook by it's own

And another one problem is detected!
Only If the ribbon is added to project.

if i open outlook first, then excel (add-in starts ok) and try to send email
from excel - the message window stays on the screen.
And it is interesting that all controls and ribbons are available and the
content box look's like in a hung state, no redrawing. Pressing a croos to
close window closes it without any arror.
Also if I just create new message from excel, and then try to close it, it
still remains on the screen (as in send case). Pressing Close once again -
closes window.
This is completely strange!
Any one may take an experiment just add Ribbon to the project, with no user
code.
I also tried to download a Hello all!
I'm experiencing some problems with outlook add-in loading if outlook was
loaded by means of Excel, Word and so on.
Here is what i'm doing:

1) Create an empty Outlook Add-in project using Visual Studio 2008, new
Project -> Visual C# -> Office -> 2007 ->

Outlook 2007 Addin
2) Into the start up method add the following

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
System.IO.StreamWriter sw = new
System.IO.StreamWriter("c:\\AddinTest.txt");
sw.WriteLine("");
sw.Close();
}
3) Run the project. Outlook starts. See that file was created on c:
4) delete file
5) Run Outlook as it self (not from debugger) and see c:, file was created
again. Delete it.
6) Run Excel 2007, then in office menu select Send, as email. Outlook new
message form is shown, new excel work

book is packed as an attach to this letter. Look at c:. NO file was created!!!
7) press CRTL+SHIFT+ESC, to start task manager, to be sure that outlook was
started. Yes you can see process

OUTLOOK.EXE in the list.
8) Still no file.
9) Close new message window, wait for 1-2 sec.
10) Look at the c:! What a surprise! here is our file!

1) So, my first question is, why it has so weird behavior?
2) And the second onr is how to avoid this problem?

Because in my real addin, I need to customise ribbon (add one combobox) when
the new message is created and

everything is fine, if I do it directly from the Outlook (or outlook is
started and i'm doing it from excel), but

it fails if Excel starts Outlook by it's own

And another one problem is detected!
Only If the ribbon is added to project.

if i open outlook first, then excel (add-in starts ok) and try to send email
from excel - the message window stays on the screen.
And it is interesting that all controls and ribbons are available and the
content box look's like in a hung state, no redrawing. Pressing a croos to
close window closes it without any arror.
Also if I just create new message from excel, and then try to close it, it
still remains on the screen (as in send case). Pressing Close once again -
closes window.
This is completely strange!
Any one may take an experiment just add Ribbon to the project, with no user
code.
I also tried to download a OutlookRibbonXCS_VSTO example from microsoft, and
replaced COntact inspector with mail inspector - got the same strange
behavior as in empty project. So i think it's a bug.
Any ideas how to struggle that?
Thank you!

 

[SomewhereSomehow]

sorry my message was duplicated several times when i tried to paste
"OutlookRibbonXCS_VSTO" from anoter place.
The end of my message is:

I also tried to download a OutlookRibbonXCS_VSTO example from microsoft, and
replaced COntact inspector with mail inspector - got the same strange
behavior as in empty project. So i think it's a bug.
Any ideas how to struggle that?
Thank you!

 

[Ken Slovak - [MVP - Outlook]]

First of all I'm not sure how VSTO is handling what is called a headless
Outlook. That's an Outlook that has no UI. Are you getting the Startup()
event when Excel starts Outlook? If not you need to display a UI by using
the GetExplorer() method. If that doesn't work you will need to post to the
VSTO forum at the MSDN forums to see what the VSTO team says about that
problem.

In the second problem you are seeing Simple MAPI items opened by sending
mail from Excel and not using the Outlook object model to do that instead. A
Simple MAPI Inspector is opened modally. It also will not start a VSTO
addin. Simple MAPI Inspectors do not fire NewInspector() when they are
opened. They do get added to the Inspectors collection, but no event fires
to tell you that.

 

[SomewhereSomehow]

Hello, Ken!
Yes, I know about the problem of NewInspector event. About 4 years ago, I
developed add-in for Outlook 2003 (actually now I'm trying to create the new
version of it, using VSTO 3.0 for Outlook 2007), and Sue Mosher from
outlookcode.com told me that there is such a problem, and adviced to check
inspector collection manually on timer. That worked out ok.
But that was developed without VSTO, just by implementing IDTExtensibility2
interface in Connect class in VS 2003 shared addin project template.

Now the thing is that Add-in starts AFTER I close the window of New Message.
So nor timer nor any user code could be used to customize message window, it
just runs after i close the window...

And another problem - about message window that stays on the screen after
send or close, I don't understood your advce?
I've allready posted a message here:

http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/99436b2b-f4ea-4c6a-a578-5196939f786f

but unfortunately got no replies...

 

[Ken Slovak - [MVP - Outlook]]

Well, my recommendation would be to use a shared addin rather than VSTO.
That way you can decide when to allow your addin to instantiate itself and
whether or not to handle Simple MAPI Inspectors and headless Outlook. I do
that myself to handle that sort of thing.

The timer thing works very well, Sue contacted me about that and I told her
how to do it. But you do need to handle cases where your timer fires before
NewInspector() so you don't handle the same Inspector more than once.

I think the delayed startup is a function of VSTO handling Extensibility
events internally and not passing them along as a Startup() event right
away. That's how it does things on startup. By removing that code between
you and OnConnection() you can handle things the way you want.

 

[SomewhereSomehow]

Thank for the explanation, Ken! I appreciate it much!
As for the first problem everything is clear now.

And can you say something about the second one?
If I open Outook, then Excel, and create new message from excel, the addin
starts ok, but if I then press send or cross to close the window. The window
stays on the screen in hung up like state. If i press close once again it is
closing with no errors.
That thing happens only if ribbon is added to project. If there is no
ribbon, just command bars - everything works fine...
I thought it may be my code mistake, but i crerated empty addin with ribbon
- the same behavior, then I took example from MS site
http://www.microsoft.com/downloads/...bf-48dc-4f73-8f6b-62b4482a92bc&displaylang=en

In OutlookRibbonXCS_VSTO project replaced "Contact" item to "Mail" item (to
make ribbon load in mail message window) and got the same behavior and hung
up window...

 

[SomewhereSomehow]

One more thing just discovered, the same behavior in the sample code you
provided on your site http://www.slovaktech.com.

I downloaded VSTO_CSOutlookProject, ran it, then ran excel, then created new
message from excel.
Then if you try to close the window everything will be ok, but if you first
select your tab VSTO_CS Addin, and then close the window - it will stay on
the screen

(As I understand as soon as customized ribbon is loaded/rendered the window
could'n close properly, my ribbon is added to the TabMailMessage so it
loads/renders as soon as window is shown, in your sample as soon as i select
VSTO_CS Addin tab - then in both cases the window stays on the screen...

 

[Ken Slovak - [MVP - Outlook]]

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.

 

[SomewhereSomehow]

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]]

If you tried to call Inspector.Close() within Inspector.Send() that will
fire an exception. That's why I use the timer. It lets Send() finish and
then it fires and calls Close().

I've only had to use WM_CLOSE in cases of Simple MAPI Inspectors, which is
using a hack to close a hacked up window

The owner of the Outlook object model is well aware of all this sort of
thing. We'd discussed it for many years and I even had showed him how to
work with Simple MAPI Inspectors back when he was an Outlook MVP and we
worked on development projects together. No real resources have been spent
on Simple MAPI Inspectors in many years and I don't expect that to change.
We're lucky they are now added to the Inspectors collection, they weren't in
Outlook 2000 or before.

 

[SomewhereSomehow]

Ok, I got it! But I just discovered that it seems to be not so bad about this
simple MAPI inspector bug! =) If you are interested, I have some good news
about that problem.
During discussion here:

http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/3ba43844-4a6e-4200-a5cb-a4d67a614fd2

we have found that this problem somehow appeares only on sp1 and doesn't
appear on office sp2.
After I've updated office 2007 sp1 to sp2 - the problem disappeared!

So now the problem is completely solved in two different ways!
Thanks for your careful attention for this topic!