none
How Do I know when Item_Write will fire after a deletion? RRS feed

  • Question

  • If I were to right click on an  AppointmentItem with more than one participant in order to delete it, the context menu will show me the "Cancel Meeting" option.

    SCENARIO 1:  The meeting was sent previously.

    If I were to select "Cancel Meeting" I would get an Inspector Window and be given the choice to "Send Cancellation".  The sequence of events that fire begin with "Item_BeforeDelete"  all the way through Item_Write and Item_AfterWrite.

    SCENARIO 2:  The meeting was never sent; it was only saved.

    If I were to select "Cancel Meeting" from the context menu (right click) the meeting would immediately be canceled.  No Inspector Window would be shown.  The only event that would fire is "Item_BeforeDelete"

    It is important for me to know when Item_BeforeDelete will fire and NOT be followed by any other events because we need to inform our custom database that a deletion has actually happened.   If we assume that the meeting is really being cancelled in this event we could accidentally be deleting a meeting that a person has changed their mind about cancelling.

    Normally we perform our deletions in the in the "Item_Write" event because I can always check the "MeetingStatus" property for the cancellation and then make our database update.

    Thursday, August 7, 2014 6:57 PM

Answers

  • PROBLEM:  Synchronizing deletions from outlook with our custom database.

    DESCRIPTION: When you delete an appointment the main events that fire (among others) are Item_BeforeDelete and Item_Write.  In the simple case when Item_Write fires I simply check the "MeetingStatus" value.  If it's olMeetingCanceled I can go ahead and perform the deletion in our custom database.

    It gets more complicated if the following conditions are in place:
    a) All the invited participants have declined the meeting

    b) When cancelling meeting you elect to Delete the meeting without sending a cancellation message.

    What happens in this scenario Item_BeforeDelete fires, but Item_Write does not.  I cannot simply go ahead and delete here because a user may change their mind and cancel the deletion process in Outlook.

    SOLUTION:
    I can check the Inbox and search for the "MeetingItem" using whatever criteria I need (e.g. creationtime and subject).  Once found I get the associated AppointmentItem with a call to GetAssociatedAppointment, then I can iterate through the list of Recipients and check the "MeetingResponseStatus" property to see if they've declined the meeting.

    If everyone's declined the meeting it should be safe to Delete the appointment back in our database.

     

    • Marked as answer by Germán_MSO Monday, August 11, 2014 12:00 PM
    Monday, August 11, 2014 12:00 PM

All replies

  • Hello German,
    It looks like you are interested in the ItemRemove event of the Items class http://msdn.microsoft.com/en-us/library/office/dn320334(v=office.15).aspx which is fired after the action.
    As a workaround you may consider repurposing the Fluent UI controls. So, you will know what the user chose. You can read more about this in the http://msdn.microsoft.com/en-us/library/bb462633(v=office.12).aspx article in MSDN.
    Thursday, August 7, 2014 7:11 PM
  • The problem with ItemRemove is that it can be called for any number of reasons.

    Using OutlookSpy I've found that ItemRemove gets called when a user "Accepts" a meeting request.  It is also called when a user proposes a new time for a meeting.   In the beginning we set up a flags for this but we quickly began to realize that we have no idea what else might be calling ItemRemove and when.

    Repurposing the controls sounds like a good idea.  I've even tested some stub code to make sure the Callbacks fire.  Let's take the "Delete" button for example.  The Callback gets called, then I guess I would have to provide my own Delete function because it looks like the normal events stop firing (e.g. Item_BeforeDelete)

    I will play with this a little and get back to you.  Do I have to provide my own delete function in a callback (assuming of course the user clicked "Delete")?

    • Edited by Germán_MSO Thursday, August 7, 2014 7:39 PM Clarification
    Thursday, August 7, 2014 7:37 PM
  • It is up to you what to do in a callback. You can handle the delete operation in the code or let it to be deleted by Outlook.

    Let me know whether it helps.
    Thursday, August 7, 2014 9:03 PM
  • I'm tied up with another issue, but I will be looking at handling the delete in the Ribbon later today.  I'll post my results as soon as I have them. 

    Thanks for jumping in on this one.

    Friday, August 8, 2014 4:22 PM
  • PROBLEM:  Synchronizing deletions from outlook with our custom database.

    DESCRIPTION: When you delete an appointment the main events that fire (among others) are Item_BeforeDelete and Item_Write.  In the simple case when Item_Write fires I simply check the "MeetingStatus" value.  If it's olMeetingCanceled I can go ahead and perform the deletion in our custom database.

    It gets more complicated if the following conditions are in place:
    a) All the invited participants have declined the meeting

    b) When cancelling meeting you elect to Delete the meeting without sending a cancellation message.

    What happens in this scenario Item_BeforeDelete fires, but Item_Write does not.  I cannot simply go ahead and delete here because a user may change their mind and cancel the deletion process in Outlook.

    SOLUTION:
    I can check the Inbox and search for the "MeetingItem" using whatever criteria I need (e.g. creationtime and subject).  Once found I get the associated AppointmentItem with a call to GetAssociatedAppointment, then I can iterate through the list of Recipients and check the "MeetingResponseStatus" property to see if they've declined the meeting.

    If everyone's declined the meeting it should be safe to Delete the appointment back in our database.

     

    • Marked as answer by Germán_MSO Monday, August 11, 2014 12:00 PM
    Monday, August 11, 2014 12:00 PM
  • Thanks for this.  I've found an alternative solution.  I ran into a few other issues with trying to re-purpose the buttons in the Inspector.  It's not that I couldn't do it, it had more to do with what we're doing in our application.

    That said, given the amount of customization we're doing with our inhouse app; I'd better get good at repurposing.  I will likely be using your suggestion in the future.

    THANKS!!

    Monday, August 11, 2014 12:02 PM