Platform SDK: MAPI |
Clients often rely on table notifications to learn of changes to objects rather than registering to receive notifications directly from the objects. Typical changes that cause notifications to be sent include the addition, deletion, or modification of a row and any critical error. When notifications arrive, clients can determine whether or not to make another call to reload the table.
Because table notifications are asynchronous, there are a few issues that can make handling notifications less than straightforward:
For example, a client might make a change to a message and then decide to delete it. The message store provider implementing the contents table that included the message sends two notifications: a TABLE_ROW_MODIFIED event followed by a TABLE_ROW_DELETED event. Depending on how the message store provider times notifications, the client might receive the TABLE_ROW_MODIFIED notification after the deletion of the row.
MAPI requires that the notification column set match the column set that was in effect at the time that the notification was generated. Because it is possible for a client to call IMAPITable::SetColumns to alter the column set at any time — including after a notification — the two column sets may not be synchronized.
That is, if a row is excluded from the view due to a restriction or because the table is in a collapsed state, no notification will be sent if that row changes. Also, no notifications are sent to inform a client about a change in category state.
Clients should be aware that not all tables support the TABLE_SORT_DONE notification and should be prepared to handle this condition by: