Aborting ItemChange if ItemRemove Event Handler will be called nex

  • Thread starter Thread starter pkelley
  • Start date Start date
Status
Not open for further replies.
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?
 
Handle that button click event and set a flag. Check that flag in the

ItemChange() and ItemRemove() events to see what actions to take, then clear

the flag.

"pkelley" <pkelley> wrote in message

news:10B1A6BB-F4D4-4DFF-890F-5771D5895D1C@microsoft.com...
> 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?
 
Status
Not open for further replies.

Similar threads

Back
Top