Inspector.CurrentItem causes Shared Calendar Issue

  • Thread starter Thread starter dotnet_ottawa
  • Start date Start date
D

dotnet_ottawa

I am having a problem with the Inspector.CurrentItem() method causing shared
calendar issues in Outlook 2003. The problem is as follows...

- user 1 and 2 share each others calendar
- user 1 creates a meeting request and sends it to user 2
- user 2 opens the meeting request, changes something [e.g. location] and
sends the update back to user 1
- user 1 sees the meeting request update on the calendar; however, when the
meeting request is opened, the OLD information is displayed, rather than the
updates

I have stripped out all add-in code and narrowed it down to the
Inspector.CurrentItem() method. This method call causes the problem, and
commenting it out makes the problem go away. I however need to test what type
of Outlook object is returned by the Inspector.CurrentItem

My stripped-down code is below.

Any ideas.


**********************************************************
Option Explicit On
Option Strict On

Imports System
Imports Microsoft.Office.Core
Imports System.Runtime.InteropServices
Imports Microsoft.win32
Imports Microsoft.Office.Interop

<GuidAttribute("213CA206-ADED-4C80-A8D6-C2B38E343234"),
ProgIdAttribute("MyAddin.Connect")> _
Public Class Connect
Implements Extensibility.IDTExtensibility2

Private WithEvents inspectors As Outlook.Inspectors
Private applicationObject As Outlook.Application

Public Sub OnBeginShutdown(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnBeginShutdown
End Sub

Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnAddInsUpdate
End Sub

Public Sub OnStartupComplete(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnStartupComplete
inspectors = Me.applicationObject.Inspectors
End Sub

Public Sub OnDisconnection(ByVal RemoveMode As
Extensibility.ext_DisconnectMode, ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnDisconnection
End Sub

Public Sub OnConnection(ByVal application As Object, ByVal connectMode
As Extensibility.ext_ConnectMode, ByVal addInInst As Object, ByRef custom As
System.Array) Implements Extensibility.IDTExtensibility2.OnConnection
applicationObject = CType(application, Outlook.Application)

End Sub

Private Sub inspectors_NewInspector(ByVal Inspector As
Microsoft.Office.Interop.Outlook.Inspector) Handles inspectors.NewInspector
'this line causes the shared calendar problem
Dim mailItem As Outlook.MailItem = CType(Inspector.CurrentItem,
Outlook.MailItem)
End Sub

End Class
**********************************************************
 
See if this helps.

Instead of trying to instantiate a MailItem object without enclosing it
inside a try...catch block use this type of code:

If (TypeOf(Inspector.CurrentItem) Is Outlook.MailItem) Then
' is a mail item, now instantiate the MailItem object
End If




dotnet_ottawa said:
I am having a problem with the Inspector.CurrentItem() method causing
shared
calendar issues in Outlook 2003. The problem is as follows...

- user 1 and 2 share each others calendar
- user 1 creates a meeting request and sends it to user 2
- user 2 opens the meeting request, changes something [e.g. location] and
sends the update back to user 1
- user 1 sees the meeting request update on the calendar; however, when
the
meeting request is opened, the OLD information is displayed, rather than
the
updates

I have stripped out all add-in code and narrowed it down to the
Inspector.CurrentItem() method. This method call causes the problem, and
commenting it out makes the problem go away. I however need to test what
type
of Outlook object is returned by the Inspector.CurrentItem

My stripped-down code is below.

Any ideas.


**********************************************************
Option Explicit On
Option Strict On

Imports System
Imports Microsoft.Office.Core
Imports System.Runtime.InteropServices
Imports Microsoft.win32
Imports Microsoft.Office.Interop

<GuidAttribute("213CA206-ADED-4C80-A8D6-C2B38E343234"),
ProgIdAttribute("MyAddin.Connect")> _
Public Class Connect
Implements Extensibility.IDTExtensibility2

Private WithEvents inspectors As Outlook.Inspectors
Private applicationObject As Outlook.Application

Public Sub OnBeginShutdown(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnBeginShutdown
End Sub

Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnAddInsUpdate
End Sub

Public Sub OnStartupComplete(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnStartupComplete
inspectors = Me.applicationObject.Inspectors
End Sub

Public Sub OnDisconnection(ByVal RemoveMode As
Extensibility.ext_DisconnectMode, ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnDisconnection
End Sub

Public Sub OnConnection(ByVal application As Object, ByVal connectMode
As Extensibility.ext_ConnectMode, ByVal addInInst As Object, ByRef custom
As
System.Array) Implements Extensibility.IDTExtensibility2.OnConnection
applicationObject = CType(application, Outlook.Application)

End Sub

Private Sub inspectors_NewInspector(ByVal Inspector As
Microsoft.Office.Interop.Outlook.Inspector) Handles
inspectors.NewInspector
'this line causes the shared calendar problem
Dim mailItem As Outlook.MailItem = CType(Inspector.CurrentItem,
Outlook.MailItem)
End Sub

End Class
**********************************************************
Click to expand...
 
Thanks Ken for the quick response.

Actually the code you provided is some of the original code that was used,
and this also causes the problem. It appears that simply calling the
CurrentItem() method is enough.

I have tried many variations including the code from
[http://support.microsoft.com/kb/327657]

Private Sub oInsps_NewInspector(ByVal Inspector As Inspector)
Set lastInspector = Application.Inspectors(Application.Inspectors.Count)
Set objTrustedItem = lastInspector.CurrentItem
End Sub

We are one Service Pack behind on Outlook 2003, we will try this today. I
read an article where the author thought that the Dec 7, 2007 SP would solve
a similar "shared calendar" issue. Will see.

I have not tried creating a wrapper class around everything to see if this
makes a difference.

I just do not understand how such simplistic code can cause this problem. We
will likely contact Microsoft directly, since as far as I can see, the code
should work.



Ken Slovak - said:
See if this helps.

Instead of trying to instantiate a MailItem object without enclosing it
inside a try...catch block use this type of code:

If (TypeOf(Inspector.CurrentItem) Is Outlook.MailItem) Then
' is a mail item, now instantiate the MailItem object
End If




dotnet_ottawa said:
I am having a problem with the Inspector.CurrentItem() method causing
shared
calendar issues in Outlook 2003. The problem is as follows...

- user 1 and 2 share each others calendar
- user 1 creates a meeting request and sends it to user 2
- user 2 opens the meeting request, changes something [e.g. location] and
sends the update back to user 1
- user 1 sees the meeting request update on the calendar; however, when
the
meeting request is opened, the OLD information is displayed, rather than
the
updates

I have stripped out all add-in code and narrowed it down to the
Inspector.CurrentItem() method. This method call causes the problem, and
commenting it out makes the problem go away. I however need to test what
type
of Outlook object is returned by the Inspector.CurrentItem

My stripped-down code is below.

Any ideas.


**********************************************************
Option Explicit On
Option Strict On

Imports System
Imports Microsoft.Office.Core
Imports System.Runtime.InteropServices
Imports Microsoft.win32
Imports Microsoft.Office.Interop

<GuidAttribute("213CA206-ADED-4C80-A8D6-C2B38E343234"),
ProgIdAttribute("MyAddin.Connect")> _
Public Class Connect
Implements Extensibility.IDTExtensibility2

Private WithEvents inspectors As Outlook.Inspectors
Private applicationObject As Outlook.Application

Public Sub OnBeginShutdown(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnBeginShutdown
End Sub

Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnAddInsUpdate
End Sub

Public Sub OnStartupComplete(ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnStartupComplete
inspectors = Me.applicationObject.Inspectors
End Sub

Public Sub OnDisconnection(ByVal RemoveMode As
Extensibility.ext_DisconnectMode, ByRef custom As System.Array) Implements
Extensibility.IDTExtensibility2.OnDisconnection
End Sub

Public Sub OnConnection(ByVal application As Object, ByVal connectMode
As Extensibility.ext_ConnectMode, ByVal addInInst As Object, ByRef custom
As
System.Array) Implements Extensibility.IDTExtensibility2.OnConnection
applicationObject = CType(application, Outlook.Application)

End Sub

Private Sub inspectors_NewInspector(ByVal Inspector As
Microsoft.Office.Interop.Outlook.Inspector) Handles
inspectors.NewInspector
'this line causes the shared calendar problem
Dim mailItem As Outlook.MailItem = CType(Inspector.CurrentItem,
Outlook.MailItem)
End Sub

End Class
**********************************************************
Click to expand...
Click to expand...
 
Do you see this problem in items opened from non-shared folders (folders the
user owns in their own mailbox)?

How are the shared folders being shared? There are many limitations on items
and folders shared using File, Open, Other User's Folder or by using the
shared calendar module. Usually things only really work right if the shared
folder is in a mailbox that is opened as part of the Outlook profile.
 
Calendar sharing is set up by clicking the "Share My calendar..." link under
"My calendars" in the Outlook Calendar view. In my case we add 2 users, each
with "Editor" permissions.

So User-X has shared their calendar with User-1 and User-2

User-1 and User-2 go through this process: In Outlook Calendar view, under
the "Other Calendars" section [under "My Calendars"] is User-X Calendar.
Clicking the checkbox will display the User-X Calendar along side the
Calendar of the logged-on user.

1) User-1 creates a meeting request on User-X calendar
2) User-2 edits the meeting request on User-X calendar and sends an update
3) User-1 opens the edited meeting request on User-X calendar, and sees the
original information and NOT the updated information

Without sharing calendars, the process of sending updates to a meeting
request is very different; however, it does work fine.

I have even tried Microsoft's own sample code to create Outlook add-ins
http://msdn.microsoft.com/en-us/library/cc668191.aspx

The sample code also has the same problem. Once the CurrentItem property of
the Inspector is obtained in the NewInspector event, the shared calendar
issue occurs.

Do you know of any other method to determine the type of item referenced by
the CurrentItem property?


Ken Slovak - said:
Do you see this problem in items opened from non-shared folders (folders the
user owns in their own mailbox)?

How are the shared folders being shared? There are many limitations on items
and folders shared using File, Open, Other User's Folder or by using the
shared calendar module. Usually things only really work right if the shared
folder is in a mailbox that is opened as part of the Outlook profile.




dotnet_ottawa said:
Thanks Ken for the quick response.

Actually the code you provided is some of the original code that was used,
and this also causes the problem. It appears that simply calling the
CurrentItem() method is enough.

I have tried many variations including the code from
[http://support.microsoft.com/kb/327657]

Private Sub oInsps_NewInspector(ByVal Inspector As Inspector)
Set lastInspector =
Application.Inspectors(Application.Inspectors.Count)
Set objTrustedItem = lastInspector.CurrentItem
End Sub

We are one Service Pack behind on Outlook 2003, we will try this today. I
read an article where the author thought that the Dec 7, 2007 SP would
solve
a similar "shared calendar" issue. Will see.

I have not tried creating a wrapper class around everything to see if this
makes a difference.

I just do not understand how such simplistic code can cause this problem.
We
will likely contact Microsoft directly, since as far as I can see, the
code
should work.
Click to expand...
Click to expand...
 
After speaking with Microsoft Support, my problem is basically a memory leak
issue between .NET and Outlook COM. The original code provided by Microsoft a
few years ago, and continued in Visual Studio 2005 Office add-in does NOT
work perfectly. This code produces a memory leak that can cause instability
in Outlook.

I even tried a wrapper class, but the solution is to use Microsoft wrapper
classes, including a specifc Inspector wrapper class. Although the Microsoft
solution was intended for Outlook 2007 and VS 2005, it is not too difficult
to port this to Outlook 2003 and VS 2003.

See:
http://www.microsoft.com/downloads/...9a-0272-4635-b158-10553779a3df&displaylang=en

I have implemented the Microsoft code and I no longer have my "shared
calendar" issue.

dotnet_ottawa said:
Calendar sharing is set up by clicking the "Share My calendar..." link under
"My calendars" in the Outlook Calendar view. In my case we add 2 users, each
with "Editor" permissions.

So User-X has shared their calendar with User-1 and User-2

User-1 and User-2 go through this process: In Outlook Calendar view, under
the "Other Calendars" section [under "My Calendars"] is User-X Calendar.
Clicking the checkbox will display the User-X Calendar along side the
Calendar of the logged-on user.

1) User-1 creates a meeting request on User-X calendar
2) User-2 edits the meeting request on User-X calendar and sends an update
3) User-1 opens the edited meeting request on User-X calendar, and sees the
original information and NOT the updated information

Without sharing calendars, the process of sending updates to a meeting
request is very different; however, it does work fine.

I have even tried Microsoft's own sample code to create Outlook add-ins
http://msdn.microsoft.com/en-us/library/cc668191.aspx

The sample code also has the same problem. Once the CurrentItem property of
the Inspector is obtained in the NewInspector event, the shared calendar
issue occurs.

Do you know of any other method to determine the type of item referenced by
the CurrentItem property?


Ken Slovak - said:
Do you see this problem in items opened from non-shared folders (folders the
user owns in their own mailbox)?

How are the shared folders being shared? There are many limitations on items
and folders shared using File, Open, Other User's Folder or by using the
shared calendar module. Usually things only really work right if the shared
folder is in a mailbox that is opened as part of the Outlook profile.




dotnet_ottawa said:
Thanks Ken for the quick response.

Actually the code you provided is some of the original code that was used,
and this also causes the problem. It appears that simply calling the
CurrentItem() method is enough.

I have tried many variations including the code from
[http://support.microsoft.com/kb/327657]

Private Sub oInsps_NewInspector(ByVal Inspector As Inspector)
Set lastInspector =
Application.Inspectors(Application.Inspectors.Count)
Set objTrustedItem = lastInspector.CurrentItem
End Sub

We are one Service Pack behind on Outlook 2003, we will try this today. I
read an article where the author thought that the Dec 7, 2007 SP would
solve
a similar "shared calendar" issue. Will see.

I have not tried creating a wrapper class around everything to see if this
makes a difference.

I just do not understand how such simplistic code can cause this problem.
We
will likely contact Microsoft directly, since as far as I can see, the
code
should work.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top