Outlook Meeting Request Bug

  • Thread starter Thread starter Tim Pulley
  • Start date Start date
T

Tim Pulley

I've found what I believe is a bug in Outlook. I can demonstrate the problem
with the following code. It's a small add-in that hooks an event on the
Application
object. The problem only happens when the add-in is installed.

I've don't see anything wrong with this code. If anyone sees a problem
please let me know.

TIA, Tim

public partial class ThisAddIn
{
private void ThisAddIn_Startup( object sender, System.EventArgs e )
{
try
{
m_application = Globals.ThisAddIn.Application;

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

}
catch( Exception X )
{
}
}

private void ThisAddIn_Shutdown( object sender, System.EventArgs e )
{
try
{
( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd -= new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

m_application = null;
}
catch( Exception X )
{
}
finally
{
}
}

private void onEvent_OptionsPagesAdd( Outlook.PropertyPages
PropertyPages )
{
return;
}

//

Outlook.Application m_application;


#region VSTO generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup( )
{
this.Startup += new System.EventHandler( ThisAddIn_Startup );
this.Shutdown += new System.EventHandler( ThisAddIn_Shutdown );
}

#endregion
}
 
Hooking an event on the Outlook Application object creates a problem with
appointments generated from meeting requests. If, after sending the meeting
request, I open and modify the appointment's body and then save the
appointment, Outlook displays a message box stating that the meeting's
attendee list has changed. [Here's my favorite part] When I close Outlook it
sends an updated meeting request even though I closed the appointment
without saving the changes. The problem only happens in the Outlook session
that generated the appointment. If I close and reopen Outlook I can change
the appointment's body and save it without any problem.

I've tried six different events and they all produce the problem. The add-in
was created using VSTO 2005 SE and I'm running a fully patched version of
Outlook 2007. But it also happens with RTM version of Outlook 2007.
 
I have never seen that happen.
Are you saying that if you comment out the following line the problem
immediately goes away?

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );


--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
Tim Pulley said:
Hooking an event on the Outlook Application object creates a problem with
appointments generated from meeting requests. If, after sending the
meeting request, I open and modify the appointment's body and then save
the appointment, Outlook displays a message box stating that the meeting's
attendee list has changed. [Here's my favorite part] When I close Outlook
it sends an updated meeting request even though I closed the appointment
without saving the changes. The problem only happens in the Outlook
session that generated the appointment. If I close and reopen Outlook I
can change the appointment's body and save it without any problem.

I've tried six different events and they all produce the problem. The
add-in was created using VSTO 2005 SE and I'm running a fully patched
version of Outlook 2007. But it also happens with RTM version of Outlook
2007.


And the bug is?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
Click to expand...
Click to expand...
 
Dmitry,

Yes, that's exactly what I'm saying. Comment out the line of code that hooks
the event and the problem disappears. I can repro the problem on multiple
systems.

When you say "I have never seen this happen" do you mean that you've tested
this and you can't reproduce the problem?


Dmitry Streblechenko said:
I have never seen that happen.
Are you saying that if you comment out the following line the problem
immediately goes away?

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );


--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
Tim Pulley said:
Hooking an event on the Outlook Application object creates a problem with
appointments generated from meeting requests. If, after sending the
meeting request, I open and modify the appointment's body and then save
the appointment, Outlook displays a message box stating that the meeting's
attendee list has changed. [Here's my favorite part] When I close Outlook
it sends an updated meeting request even though I closed the appointment
without saving the changes. The problem only happens in the Outlook
session that generated the appointment. If I close and reopen Outlook I
can change the appointment's body and save it without any problem.

I've tried six different events and they all produce the problem. The
add-in was created using VSTO 2005 SE and I'm running a fully patched
version of Outlook 2007. But it also happens with RTM version of Outlook
2007.


And the bug is?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
"Tim Pulley" <tpulley_at_mantech-ist_dot_com> wrote in message
I've found what I believe is a bug in Outlook. I can demonstrate the
problem
with the following code. It's a small add-in that hooks an event on the
Application
object. The problem only happens when the add-in is installed.

I've don't see anything wrong with this code. If anyone sees a problem
please let me know.

TIA, Tim

public partial class ThisAddIn
{
private void ThisAddIn_Startup( object sender, System.EventArgs
e )
{
try
{
m_application = Globals.ThisAddIn.Application;

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

}
catch( Exception X )
{
}
}

private void ThisAddIn_Shutdown( object sender, System.EventArgs
e )
{
try
{
( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd -= new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

m_application = null;
}
catch( Exception X )
{
}
finally
{
}
}

private void onEvent_OptionsPagesAdd( Outlook.PropertyPages
PropertyPages )
{
return;
}

//

Outlook.Application m_application;


#region VSTO generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup( )
{
this.Startup += new System.EventHandler( ThisAddIn_Startup );
this.Shutdown += new System.EventHandler(
ThisAddIn_Shutdown );
}

#endregion
}
Click to expand...
Click to expand...
Click to expand...
 
I mean I use Application events all over the place and I have never
experienced this.I do not use VSTO or ,.Net though.
Try an experiment: disable your add-in and install OutlookSpy. Start Outlook
and click on teh Application button on teh OutlookSpy toolbar, go to the
Events tab. Leave the window open. Can you reproduce the appointment problem
while that window is still open (it hooks up the Application events)?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
Tim Pulley said:
Dmitry,

Yes, that's exactly what I'm saying. Comment out the line of code that
hooks
the event and the problem disappears. I can repro the problem on multiple
systems.

When you say "I have never seen this happen" do you mean that you've
tested
this and you can't reproduce the problem?


Dmitry Streblechenko said:
I have never seen that happen.
Are you saying that if you comment out the following line the problem
immediately goes away?

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );


--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
Tim Pulley said:
Hooking an event on the Outlook Application object creates a problem
with
appointments generated from meeting requests. If, after sending the
meeting request, I open and modify the appointment's body and then save
the appointment, Outlook displays a message box stating that the
meeting's
attendee list has changed. [Here's my favorite part] When I close
Outlook
it sends an updated meeting request even though I closed the
appointment
without saving the changes. The problem only happens in the Outlook
session that generated the appointment. If I close and reopen Outlook I
can change the appointment's body and save it without any problem.

I've tried six different events and they all produce the problem. The
add-in was created using VSTO 2005 SE and I'm running a fully patched
version of Outlook 2007. But it also happens with RTM version of
Outlook
2007.



And the bug is?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
"Tim Pulley" <tpulley_at_mantech-ist_dot_com> wrote in message
I've found what I believe is a bug in Outlook. I can demonstrate the
problem
with the following code. It's a small add-in that hooks an event on
the
Application
object. The problem only happens when the add-in is installed.

I've don't see anything wrong with this code. If anyone sees a
problem
please let me know.

TIA, Tim

public partial class ThisAddIn
{
private void ThisAddIn_Startup( object sender,
System.EventArgs
e )
{
try
{
m_application = Globals.ThisAddIn.Application;

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

}
catch( Exception X )
{
}
}

private void ThisAddIn_Shutdown( object sender,
System.EventArgs
e )
{
try
{
( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd -= new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

m_application = null;
}
catch( Exception X )
{
}
finally
{
}
}

private void onEvent_OptionsPagesAdd( Outlook.PropertyPages
PropertyPages )
{
return;
}

//

Outlook.Application m_application;


#region VSTO generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup( )
{
this.Startup += new System.EventHandler(
ThisAddIn_Startup );
this.Shutdown += new System.EventHandler(
ThisAddIn_Shutdown );
}

#endregion
}
Click to expand...
Click to expand...
Click to expand...
 
FWIW, I do use VSTO and shared managed code addins and have also never seen
anything like that. The only times I've seen something similar was when I
was testing earlier versions of the Apple ITunes addin before it was fixed,
possibly some misbehaving addin is also running.
 
Ken and Dimetry,

I probably should have titled this Outlook / VSTO 2005 SE Meeting Request
bug.

The problem is caused by the add-in. It is the only add-in / extension
loaded. I've disabled all add-ins via the Trust Center. I've double checked
the LoadBehavior registry value for each add-in (under both the HKLM and
HKCU registry keys). I also checked the Exchange Extension registry key.

I've tested using Outlook 2007 RTM thru SP1 on 5 different systems and it's
consistently reproducible. It happens when the code is compiled on my
development VMs, our build system or a non-VM development workstation. It
happens on my Development VMs (XP-SP2, VS 2005 SP1, VSTO 2005 SE and Office
2007 [RTM and SP1]) and our test VMs (XP-SP2, VSTO 2005 SE runtime and
Office 2007 SP1).

I've modified the demo code so that the application event can be hooked /
unhooked from the explorer's menu and the problem still happens. If you want
to try this out let me know and I'll send you the code for the add-in.

So is there anything wrong with the code?
 
See if the same thing happens with one of my VSTO addin templates. They're
posted at http://www.slovaktech.com/outlook_2007_templates.htm.

They were developed on VS 2005 SP1, WinXP SP2, Outlook 12 RTM, VSTO 2005SE.

Also, make sure you are using the revised VSTO runtime.

I'd take a look at the onEvent_OptionsPagesAdd() event handler and compare
it to mine. I'm not sure Outlook would take to the way you're doing it.
 
Ken,

The updated runtime is installed. All the VMs were created specifically for
this project so they've never had VSTO 2005 (1st edition) installed.

I've looked at your template and my event handler and I don't know why you
say that Outlook wouldn't like my event handler. The call to hook the event
looks right. The event handler's signature is correct. It doesn't do
anything, which is OK. What do you think is wrong?

I tested this with following five application events

ContextMenuClose
ItemContextMenuDisplay
OptionsPagesAdd
ViewContextMenuDisplay
ItemSend

and they all produced the problem.

With the exception of the ItemSend, I choose these events because they
wouldn't fire. I wanted to exclude interaction between my event handlers and
Outlook.

To test this I open Outlook, go to the calendar, create a meeting request
using the keyboard shortcut and send it. I open the appointment, type in the
body and then click the save button at the top of the form.

Thanks for taking the time to help.

Tim
 
FYI...I just got off the phone w/MS tech support and they can repro the the
problem.

Tim

Ken Slovak - said:
See if the same thing happens with one of my VSTO addin templates. They're
posted at http://www.slovaktech.com/outlook_2007_templates.htm.

They were developed on VS 2005 SP1, WinXP SP2, Outlook 12 RTM, VSTO 2005SE.

Also, make sure you are using the revised VSTO runtime.

I'd take a look at the onEvent_OptionsPagesAdd() event handler and compare
it to mine. I'm not sure Outlook would take to the way you're doing it.




Tim Pulley said:
Ken and Dimetry,

I probably should have titled this Outlook / VSTO 2005 SE Meeting Request
bug.

The problem is caused by the add-in. It is the only add-in / extension
loaded. I've disabled all add-ins via the Trust Center. I've double
checked the LoadBehavior registry value for each add-in (under both the
HKLM and HKCU registry keys). I also checked the Exchange Extension
registry key.

I've tested using Outlook 2007 RTM thru SP1 on 5 different systems and
it's consistently reproducible. It happens when the code is compiled on my
development VMs, our build system or a non-VM development workstation. It
happens on my Development VMs (XP-SP2, VS 2005 SP1, VSTO 2005 SE and
Office 2007 [RTM and SP1]) and our test VMs (XP-SP2, VSTO 2005 SE runtime
and Office 2007 SP1).

I've modified the demo code so that the application event can be hooked /
unhooked from the explorer's menu and the problem still happens. If you
want to try this out let me know and I'll send you the code for the
add-in.

So is there anything wrong with the code?
Click to expand...
Click to expand...
 
Interesting. I'll see if I can repro it here, in both managed and unmanaged
code. I'm curious where the bug is, in Outlook or the PIA.

Have you tested this at all on Outlook 2003, or only on 2007?
 
Ken,

It's very easy to repro. Just hook an application event. I have several
small demo add-ins if you're interested.

We're re-writting our app in .Net for Outlook & Exchange 2007 so I've only
tested with Outlook '07. I haven't had time to go back and test w/ Outlook
'03.

It appears to be a problem in the PIA. I took Dimtry's suggestion and used
OutlookSpy to hook Application events and I couldn't repro the problem.

I heard from the MS tech this afternoon and the work-around is to call
Marshall.ReleaseComObject on the Item in the ItemSend event. It appears to
work. Setting the Item to null doesn't.

Tim
 
Thanks. Unfortunately completely releasing the object in Send isn't a real
good solution in many cases.

For one example, you do some item processing in Send and then have to start
up a timer object to allow closing the Inspector using code, something that
will cause an exception if you do it in the Send event. So you set a timer
for a short interval at the end of Send and when the timer fires you call
Inspector.Close().

Calling Marshal.ReleaseComObject() on the item in Send would prevent that
code from working at all.

I'll see if I can verify your bug here and if so I'll file it with the
product group. That way we can be sure that they're aware of it. A lot of
times if first line support files something it gets lost in the shuffle.
It's only if you get to the higher-ups on the support front that their bug
reports are paid attention to.

Why don't you email me a couple of your small samples please, use my posting
address, I'll get them. Then I can review them and see what's going on. If
you don't mind giving me the name of the PSS engineer you worked with and
the bug case # too, that would help when I get back to the product group.
 
Ken,

I've sent you an email with the info you requested. Let me know if you don't
get it.

Thanks, Tim
 
Hi Ken,

i got the same problem. I wrote an add-in for MS Outlook 2007 in C# VSTO SE on Visual Studio 2005. Since I used only one ApplicationEvent (ItemSend) the dialog no longer appeared.

Try the following (it worked for me):

When the Meeting window (inspector) is closed, force a garbage collection. My code looks looks like this:

void Inspector_Close()
{
GC.Collect();
GC.WaitForPendingFinalizers();

...
}

If you now reopen your meeting item and make changes the dialog should appear like before.

By the way: This "inner memory leaks" also occur if you access the Inspector.CurrentItem property, so be carefull :-)
I've found what I believe is a bug in Outlook. I can demonstrate the problem
with the following code. It's a small add-in that hooks an event on the
Application
object. The problem only happens when the add-in is installed.

I've don't see anything wrong with this code. If anyone sees a problem
please let me know.

TIA, Tim

public partial class ThisAddIn
{
private void ThisAddIn_Startup( object sender, System.EventArgs e )
{
try
{
m_application = Globals.ThisAddIn.Application;

( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd += new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

}
catch( Exception X )
{
}
}

private void ThisAddIn_Shutdown( object sender, System.EventArgs e )
{
try
{
( (Outlook.ApplicationEvents_11_Event)
m_application ).OptionsPagesAdd -= new
Outlook.ApplicationEvents_11_OptionsPagesAddEventHandler(
onEvent_OptionsPagesAdd );

m_application = null;
}
catch( Exception X )
{
}
finally
{
}
}

private void onEvent_OptionsPagesAdd( Outlook.PropertyPages
PropertyPages )
{
return;
}

//

Outlook.Application m_application;


#region VSTO generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup( )
{
this.Startup += new System.EventHandler( ThisAddIn_Startup );
this.Shutdown += new System.EventHandler( ThisAddIn_Shutdown );
}

#endregion
}
On Friday, April 25, 2008 2:39 PM Dmitry Streblechenko wrote:
And the bug is?

--
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
-
"Tim Pulley" <tpulley_at_mantech-ist_dot_com> wrote in message
Click to expand...
On Friday, April 25, 2008 3:04 PM Tim Pulley wrote:
Hooking an event on the Outlook Application object creates a problem with
appointments generated from meeting requests. If, after sending the meeting
request, I open and modify the appointment's body and then save the
appointment, Outlook displays a message box stating that the meeting's
attendee list has changed. [Here's my favorite part] When I close Outlook it
sends an updated meeting request even though I closed the appointment
without saving the changes. The problem only happens in the Outlook session
that generated the appointment. If I close and reopen Outlook I can change
the appointment's body and save it without any problem.

I've tried six different events and they all produce the problem. The add-in
was created using VSTO 2005 SE and I'm running a fully patched version of
Outlook 2007. But it also happens with RTM version of Outlook 2007.


news:%[email protected]...
Click to expand...
Click to expand...
On Wednesday, April 30, 2008 1:44 PM Ken Slovak - [MVP - Outlook] wrote:
FWIW, I do use VSTO and shared managed code addins and have also never seen
anything like that. The only times I've seen something similar was when I
was testing earlier versions of the Apple ITunes addin before it was fixed,
possibly some misbehaving addin is also running.




news:%[email protected]...
Click to expand...
Click to expand...
On Thursday, May 01, 2008 3:21 PM Tim Pulley wrote:
Ken and Dimetry,

I probably should have titled this Outlook / VSTO 2005 SE Meeting Request
bug.

The problem is caused by the add-in. It is the only add-in / extension
loaded. I've disabled all add-ins via the Trust Center. I've double checked
the LoadBehavior registry value for each add-in (under both the HKLM and
HKCU registry keys). I also checked the Exchange Extension registry key.

I've tested using Outlook 2007 RTM thru SP1 on 5 different systems and it's
consistently reproducible. It happens when the code is compiled on my
development VMs, our build system or a non-VM development workstation. It
happens on my Development VMs (XP-SP2, VS 2005 SP1, VSTO 2005 SE and Office
2007 [RTM and SP1]) and our test VMs (XP-SP2, VSTO 2005 SE runtime and
Office 2007 SP1).

I've modified the demo code so that the application event can be hooked /
unhooked from the explorer's menu and the problem still happens. If you want
to try this out let me know and I'll send you the code for the add-in.

So is there anything wrong with the code?


news:[email protected]...
Click to expand...
Click to expand...
On Thursday, May 01, 2008 6:58 PM Ken Slovak - [MVP - Outlook] wrote:
See if the same thing happens with one of my VSTO addin templates. They're
posted at http://www.slovaktech.com/outlook_2007_templates.htm.

They were developed on VS 2005 SP1, WinXP SP2, Outlook 12 RTM, VSTO 2005SE.

Also, make sure you are using the revised VSTO runtime.

I'd take a look at the onEvent_OptionsPagesAdd() event handler and compare
it to mine. I'm not sure Outlook would take to the way you're doing it.




"Tim Pulley" <tpulley_at_mantech-ist_dot_com> wrote in message
news:[email protected]...
Click to expand...
Click to expand...
I just got off the phone w/MS tech support and they can repro the the
problem.

Tim

"Ken Slovak - [MVP - Outlook]" wrote:
Click to expand...
Click to expand...
On Tuesday, May 06, 2008 7:06 PM Ken Slovak - [MVP - Outlook] wrote:
Interesting. I'll see if I can repro it here, in both managed and unmanaged
code. I'm curious where the bug is, in Outlook or the PIA.

Have you tested this at all on Outlook 2003, or only on 2007?




news:[email protected]...
Click to expand...
Click to expand...
On Wednesday, May 07, 2008 3:58 PM TimPulle wrote:
Ken,

It's very easy to repro. Just hook an application event. I have several
small demo add-ins if you're interested.

We're re-writting our app in .Net for Outlook & Exchange 2007 so I've only
tested with Outlook '07. I haven't had time to go back and test w/ Outlook
'03.

It appears to be a problem in the PIA. I took Dimtry's suggestion and used
OutlookSpy to hook Application events and I couldn't repro the problem.

I heard from the MS tech this afternoon and the work-around is to call
Marshall.ReleaseComObject on the Item in the ItemSend event. It appears to
work. Setting the Item to null doesn't.

Tim

"Ken Slovak - [MVP - Outlook]" wrote:
Click to expand...
Click to expand...
On Wednesday, May 07, 2008 4:24 PM Ken Slovak - [MVP - Outlook] wrote:
Thanks. Unfortunately completely releasing the object in Send isn't a real
good solution in many cases.

For one example, you do some item processing in Send and then have to start
up a timer object to allow closing the Inspector using code, something that
will cause an exception if you do it in the Send event. So you set a timer
for a short interval at the end of Send and when the timer fires you call
Inspector.Close().

Calling Marshal.ReleaseComObject() on the item in Send would prevent that
code from working at all.

I'll see if I can verify your bug here and if so I'll file it with the
product group. That way we can be sure that they're aware of it. A lot of
times if first line support files something it gets lost in the shuffle.
It's only if you get to the higher-ups on the support front that their bug
reports are paid attention to.

Why don't you email me a couple of your small samples please, use my posting
address, I'll get them. Then I can review them and see what's going on. If
you don't mind giving me the name of the PSS engineer you worked with and
the bug case # too, that would help when I get back to the product group.




news:[email protected]...
Click to expand...
Click to expand...
On Friday, May 09, 2008 9:48 AM TimPulle wrote:
Ken,

I have sent you an email with the info you requested. Let me know if you do not
get it.

Thanks, Tim

"Ken Slovak - [MVP - Outlook]" wrote:
Click to expand...
Click to expand...
Click to expand...
 
Back
Top