One of the problems I often hear about from Outlook developers is that the sequencing of a particular event isn’t ideal for what they are trying to do. While sometimes this can be a hole in the Outlook platform, more often than not it’s because the developer isn’t using the best event for the scenario they are trying to build. Outlook often has multiple events that fire related to particular actions in the UI, and choosing the right event is important to ensure data consistency.
For example, recently I was helping a partner team who wanted to examine the contents of a meeting request when the user has actually sent the request. During this event, they would compare the state of the meeting in their system against the meeting that the user was sending, and fix up any inconsistencies in their database. The developer had found the AppointmentItem_Send event in the object model, and naturally presumed that was the right event to use. However, they started to notice that inconsistencies were occurring between items in Outlook and their database. Multiple-client issues aside, the problem is because of the event they used.
The Item_Send event fires when the user clicks the Send button on sendable items (Meeting requests, e-mail messages, etc). However, there are cases where the user can back out of sending the item after they click the send button. In this particular case, when a meeting is changed, the user is sometimes given a choice to send the updates to added/removed recipients, or to all recipients. If the user clicks cancel on this dialog, the send is canceled even though the Send event has fired.
To work around this issue, I instructed the developer to listen for the Application_ItemSend event instead. This event fires after the user has committed to sending the message and ensures that the recipients on the item reflect the state of the item after the inspector has been closed.
Likewise, there is a Close event on each of the item classes, as well as a Close event on the Inspector object. To ensure that you inspect the contents of the item after all edits have occurred, catching the Inspector_Close event will provide you with the best chance to see that information. After Item_Close has fired, there is still a chance the user will back out of the changes (for example, if they click No to save their changes).
There are times where using the Item_Close and Item_Send events are very useful though. For example, if you want to be able to cancel the event and prevent the item from being closed or sent, these events have a Cancel parameter which can be set to True to prevent the action from occurring. The more deterministic events on the Inspector and Application object are not cancelable, because that would affect their determinism.