Événements de l’assembly PIA Outlook
En parcourant l'assembly PIA (Primary Interop Assembly) Outlook, vous remarquerez peut-être que de nombreuses interfaces et délégués d'événements portent le nom d'objets familiers dans le modèle objet Outlook. Contrairement aux événements dans la bibliothèque de types COM, les événements de l'assembly PIA Outlook ne sont pas définis dans la même interface que les méthodes et propriétés du même objet. Les interfaces, délégués et classes d'assistance de récepteur liés aux événements sont importés ou créés afin de prendre en charge les événements dans l'assembly PIA Outlook. Cette rubrique décrit ces interfaces, délégués et classes d'assistance de récepteur liés aux événements.
Provenance des interfaces, délégués et classes d’assistance de récepteur liés aux événements
Pour créer l'assembly PIA Outlook, Outlook emploie l'importateur de bibliothèques de types (TLBIMP) dans le .NET Framework pour convertir les définitions de types dans la bibliothèque de types COM en définitions équivalentes dans un assembly CLR (Common Language Runtime). TLBIMP importe les deux types d'interfaces suivants pour chaque objet :
l'interface principale (par exemple, l'interface _Application ) ;
l'interface d'événement (par exemple, l'interface ApplicationEvents_11 ).
TLBIMP traite les interfaces importées et crée un certain nombre d'interfaces, délégués et classes, y compris les interfaces .NET (par exemple, l'interface Application ). Si l'objet possède des événements, les éléments suivants sont créés :
l'interface d'événement .NET (par exemple, l'interface ApplicationEvents_11_Event ) ;
un délégué pour chaque événement (par exemple, le délégué ApplicationEvents_11_ItemSendEventHandler ) ;
une classe d'assistance de récepteur (par exemple, la classe ApplicationEvents_11_SinkHelper ).
Versions multiples des événements
Certains objets qui existent pour plusieurs versions d'Outlook ont différentes implémentations d'événements d'une version à une autre, et des événements supplémentaires ont été ajoutés lors de la publication des nouvelles versions. Pour prendre en charge les événements qui varient d'une version à une autre, Outlook effectue une distinction entre ces interfaces, délégués et classes liés aux événements en ajoutant un numéro de version à leur nom. Par exemple :
Les interfaces d'événements importées de l'objet Application incluent :
la version la plus ancienne pour Outlook 98 et Outlook 2000 : l'interface ApplicationEvents ;
la version pour Outlook 2002 : l'interface ApplicationEvents_10 ;
la version pour Outlook 2003 et versions ultérieures : l'interface ApplicationEvents_11 .
Les interfaces d'événements .NET créées par TLBIMP pour l'objet Application incluent :
la version la plus ancienne pour Outlook 98 et Outlook 2000 : l'interface ApplicationEvents_Event ;
la version pour Outlook 2002 : l'interface ApplicationEvents_10_Event ;
la version pour Outlook 2003 et versions ultérieures : l'interface ApplicationEvents_11_Event .
Les délégués créés par TLBIMP pour chaque événement dans chaque version de l’objet Application, par exemple un délégué pour chaque version de l’événement ItemSend:
la version la plus ancienne pour Outlook 98 et Outlook 2000 : le délégué ApplicationEvents_ItemSendEventHandler ;
la version pour Outlook 2002 : le délégué ApplicationEvents_10_ItemSendEventHandler ;
la version pour Outlook 2003 et versions ultérieures : le délégué ApplicationEvents_11_ItemSendEventHandler .
Logiquement, les événements ajoutés à une version ultérieure n'apparaissent pas dans les interfaces d'événements de versions antérieures et n'ont aucun délégué correspondant dans les versions antérieures. Par exemple, comme l’événement AttachmentSelectionChange a été ajouté à l’objet Explorer dans Outlook 2010, il ne fait pas partie des interfaces d’événements antérieures suivantes pour l’objet Explorer :
Interface ExplorerEvents
interface ExplorerEvents_Event
En revanche, vous pouvez trouver l’événement dans l’interface d’événement .NET la plus récente, ExplorerEvents_10_Event, et son délégué pour la version Outlook 2010 , ExplorerEvents_10_AttachmentSelectionChangeEventHandler.
Rôle des interfaces, délégués et classes d’assistance de récepteur liés aux événements
À l’aide de l’objet Application comme exemple, cette section décrit ce que contient chaque interface et classe listée ci-dessus :
L'interface principale, _Application, définit toutes les méthodes et propriétés de Application. On n'utilise généralement pas cette interface dans le code, hormis dans un scénario décrit ci-dessous.
Les interfaces d'événements importées par TLBIMP, telles que ApplicationEvents_11 et ApplicationEvents_10, définissent le mappage des méthodes aux événements de Application dans la version correspondante d'Outlook. Vous n'utilisez pas cette interface dans le code.
Les interfaces d'événements importées par TLBIMP, telles que ApplicationEvents_11_Event et ApplicationEvents_10_Event, définissent tous les événements de Application dans la version correspondante d'Outlook. Lors de la conception d'un gestionnaire d'événements pour un événement dans une version spécifique, vous devez implémenter le gestionnaire d'événements en tant que méthode et connecter la méthode à l'événement défini dans la version correspondante de l'interface d'événements .NET. On ne fait généralement pas référence à l'interface d'événements dans le code, hormis dans un scénario décrit ci-dessous.
L'interface .NET, Application, hérite des interfaces _Application et ApplicationEvents_11_Event. En général, il s'agit de l'interface que l'on utilise dans le code managé pour accéder à l'objet, à la méthode, à la propriété et aux membres d'événements les plus récents de l'objet Application. Il existe toutefois deux exceptions où l'on n'utilise pas l'interface .NET mais une interface différente pour la connexion à un événement :
Lorsque vous accédez à un événement qui a le même nom qu'une méthode de cet objet, vous devez effectuer un cast vers l'interface d'événement appropriée afin d'établir la connexion à l'événement. Par exemple, pour vous connecter à l'événement Quit , vous devez effectuer un cast vers l'interface ApplicationEvents_11_Event.
Lorsque vous vous connectez à une version antérieure d'un événement qui a été étendu dans une version ultérieure d'Outlook, connectez-vous à la version de l'événement dans l'interface antérieure. Par exemple, si vous souhaitez vous connecter à la version de l'événement Quit de l'objet Application implémentée pour Outlook 2002 au lieu de la version la plus récente, connectez-vous à l'événement Quit défini dans l'interface ApplicationEvents_10_Event plutôt qu'à l'événement Quit défini dans l'interface ApplicationEvents_11_Event.
Les délégués procurent une infrastructure vous permettant de créer des gestionnaires d'événements personnalisés pour des événements spécifiques dans une version spécifique d'Outlook. Par exemple, si vous souhaitez ajouter un contrôle vérifiant l'existence d'une ligne d'objet dans un élément Outlook juste avant de l'envoyer, vous devez implémenter ce contrôle dans une méthode de rappel ayant la même signature que le délégué, ApplicationEvents_11_ItemSendEventHandler. Ensuite, vous raccordez la méthode de rappel en tant que gestionnaire d’événements pour l’événement ItemSend défini dans l’interface ApplicationEvents_11_Event. Pour plus d’informations sur la connexion de la méthode de rappel en tant que gestionnaire d’événements pour un objet, voir Connexion à des gestionnaires d’événements personnalisés.
Les classes d’assistance de récepteur créées par TLBIMP, par exemple, ApplicationEvents_11_SinkHelper et ApplicationEvents_10_SinkHelper, sont des objets d’assistance d’événement pour les événements Application dans la version correspondante d’Outlook. N’utilisez pas ces classes dans le code.