P
pkelley
Outlook 2007 Add-In
2005 VSTO Second Edition
In Outlook 2007, with regard to an existing AppointmentItem, when pressing
the "Send Cancellation" Button you get 2 Events: ItemRemove, and ItemChange.
In my experience, the ItemChange Event will fire first, followed by the
ItemRemove Event.
In my Add-In, I have the handle to the current AppointmentItem in both the
ItemChange and ItemRemove Event Handlers.
From within the ItemChange Event Handler, I want to be able to determine
that I can abort immediately since my ItemRemove Event Handler will be called
next.
In my application's case, there is no sense in executing any of the
ItemChange code if the ItemRemove code is about to be called and executed.
I thought I had stumbled onto the answer when I discovered the property:
Microsoft.Office.Interop.Outlook.OlMeetingStatus (olNonMeeting=0,
olMeeting=1, olMeetingReceived=3, olMeetingCanceled=5,
olMeetingReceivedAndCanceled=7), to be contained within the AppointmentItem
Object itself. But sadly, when my ItemChange Event Handler fired, the
current value of the current AppointmentItem was "olMeeting" - I was
expecting to see "olMeetingCanceled".
When my ItemChange Event Handler fires, I do NOT want to continue executing
my ItemChange code if the ItemRemove code is about to be called.
Can anybody think of a way to solve this problem?
2005 VSTO Second Edition
In Outlook 2007, with regard to an existing AppointmentItem, when pressing
the "Send Cancellation" Button you get 2 Events: ItemRemove, and ItemChange.
In my experience, the ItemChange Event will fire first, followed by the
ItemRemove Event.
In my Add-In, I have the handle to the current AppointmentItem in both the
ItemChange and ItemRemove Event Handlers.
From within the ItemChange Event Handler, I want to be able to determine
that I can abort immediately since my ItemRemove Event Handler will be called
next.
In my application's case, there is no sense in executing any of the
ItemChange code if the ItemRemove code is about to be called and executed.
I thought I had stumbled onto the answer when I discovered the property:
Microsoft.Office.Interop.Outlook.OlMeetingStatus (olNonMeeting=0,
olMeeting=1, olMeetingReceived=3, olMeetingCanceled=5,
olMeetingReceivedAndCanceled=7), to be contained within the AppointmentItem
Object itself. But sadly, when my ItemChange Event Handler fired, the
current value of the current AppointmentItem was "olMeeting" - I was
expecting to see "olMeetingCanceled".
When my ItemChange Event Handler fires, I do NOT want to continue executing
my ItemChange code if the ItemRemove code is about to be called.
Can anybody think of a way to solve this problem?