À propos des notifications de table
S’applique à : Outlook 2013 | Outlook 2016
Les clients s’appuient souvent sur les notifications de table pour découvrir les modifications apportées aux objets au lieu de s’inscrire pour recevoir des notifications directement à partir des objets. Les modifications classiques qui entraînent l’envoi de notifications incluent l’ajout, la suppression ou la modification d’une ligne et toute erreur critique. Lorsque les notifications arrivent, les clients peuvent déterminer s’il faut effectuer un autre appel pour recharger la table.
Étant donné que les notifications de table sont asynchrones, il existe quelques problèmes qui peuvent rendre la gestion des notifications moins simple que simple :
Les données transmises dans la structure TABLE_NOTIFICATION peuvent ne pas représenter l’état le plus actuel de la table. Par exemple, un client peut apporter une modification à un message, puis décider de le supprimer. Le fournisseur de magasin de messages implémentant la table de contenu qui inclut le message envoie deux notifications : un événement TABLE_ROW_MODIFIED suivi d’un événement TABLE_ROW_DELETED. Selon la façon dont le fournisseur de magasin de messages timese les notifications, le client peut recevoir la notification TABLE_ROW_MODIFIED après la suppression de la ligne.
L’ensemble de colonnes inclus dans une notification peut être différent de l’ensemble de colonnes actuel de la table. MAPI exige que le jeu de colonnes de notification corresponde au jeu de colonnes qui était en vigueur au moment où la notification a été générée. Étant donné qu’il est possible pour un client d’appeler IMAPITable ::SetColumns pour modifier le jeu de colonnes à tout moment, y compris après une notification, les deux jeux de colonnes peuvent ne pas être synchronisés.
Les notifications de table sont envoyées uniquement pour les lignes qui font partie de la vue. Autrement dit, si une ligne est exclue de la vue en raison d’une restriction ou parce que la table est dans un état réduit, aucune notification n’est envoyée si cette ligne change. En outre, aucune notification n’est envoyée pour informer un client d’un changement d’état de catégorie.
Les clients doivent savoir que toutes les tables ne prennent pas en charge la notification TABLE_SORT_DONE et doivent être prêts à gérer cette condition en :
Forcer le tri à être synchrone.
Rechargement des lignes de la table lorsque IMAPITable ::SortTable retourne.