Gestion des événements dans un contrôleur Automation
Remonter à Ecriture de code client basé sur les définitions de la bibliothèque de types
Lorsque vous générez un wrapper de composant pour un objet dont vous importez la bibliothèque de types, vous pouvez répondre aux événements en utilisant simplement les événements ajoutés au composant généré. Néanmoins, si vous n'utilisez pas un wrapper de composant (ou si le serveur utilise des événements COM+), vous devez écrire vous-même le code du collecteur d'événements.
Gestion des événements Automation par code
Avant de pouvoir gérer les événements, vous devez définir un collecteur d'événements. C'est une classe qui implémente l'interface de répartition des événements qui est définie dans la bibliothèque de types du serveur.
Pour écrire le collecteur d'événements, créez un objet qui implémente l'interface de répartition des événements :
TServerEventsSink = class(TObject, _TheServerEvents)
...{ declare the methods of _TheServerEvents here }
end;
class MyEventSinkClass: TEventDispatcher<MyEventSinkClass, DIID_TheServerEvents>
{
...// declare the methods of DIID_TheServerEvents here
}
Quand vous disposez d'une instance de votre collecteur d'événements, vous devez informer l’objet serveur de son existence afin que le serveur puisse l'appeler. Pour ce faire, appelez la procédure globale InterfaceConnect en lui transmettant :
- L'interface du serveur qui génère les événements.
- Le GUID de l'interface événement que gère votre collecteur d'événements.
- Une interface IUnknown pour votre collecteur d'événements.
- Une variable qui reçoit un Longint représentant la connexion entre le serveur et votre collecteur d'événements.
{MyInterface is the server interface you got when you connected to the server }
InterfaceConnect(MyInterface, DIID_TheServerEvents,
MyEventSinkObject as IUnknown, cookievar);
pInterface = CoServerClassName.CreateRemote("Machine1");
MyEventSinkClass ES;
ES.ConnectEvents(pInterface);
Après avoir appelé InterfaceConnect, votre collecteur d'événements est connecté et reçoit les appels du serveur quand des événements se produisent.
Vous devez terminer la connexion avant de libérer le collecteur d'événements. Pour ce faire, appelez la procédure globale InterfaceDisconnect en lui transmettant les mêmes paramètres, sauf l’interface de votre collecteur d'événements (le paramètre final étant en entrée et non plus en sortie) :
InterfaceDisconnect(MyInterface, DIID_TheServerEvents, cookievar);
ES.DisconnectEvents(pInterface);
Remarque : Vous devez être certain que le serveur a libéré sa connexion avec votre collecteur d'événements avant de libérer le collecteur. Comme vous ne savez pas comment le serveur répond à la notification de déconnexion initiée par InterfaceDisconnect, cela peut entraîner une condition si vous libérez votre collecteur d'événements immédiatement après l’appel. Le moyen le plus simple de vous prémunir contre cela est que votre collecteur d'événements gère son propre compteur de références qui n'est pas décrémenté tant que le serveur n'a pas libéré l’interface du collecteur d'événements.
Gestion des événements COM+
Avec COM+, les serveurs utilisent un objet utilitaire spécial pour générer des événements à la place d'un groupe d'interfaces spéciales (IConnectionPointContainer et IConnectionPoint). Donc, vous ne pouvez pas utiliser un collecteur d'événements qui descend de TEventDispatcher. TEventDispatcher est conçue pour fonctionner avec ces interfaces, pas avec des objets événement COM+.
Au lieu de définir un collecteur d'événements, votre application client définit un objet abonné. Comme les collecteurs d'événements, les objets abonné fournissent l'implémentation de l'interface événement. Ils sont différents des collecteurs d'événements car ils décrivent un objet événement particulier et non une connexion avec un point de connexion d'un serveur.
Pour définir un objet abonné, utilisez l'expert Objet COM, en sélectionnant l'interface de l'objet événement que vous voulez implémenter. L'expert génère une unité d'implémentation avec des squelettes de méthodes que vous pouvez renseigner pour créer vos gestionnaires d'événements.
Remarque : Vous pouvez avoir à ajouter l'interface de l'objet événement dans le registre en utilisant l'expert si elle n’apparaît pas dans la liste des interfaces que vous pouvez implémenter.
Une fois l'objet abonné créé, vous devez vous abonner à l'interface de l'objet événement ou individuellement aux méthodes (événements) de cette interface. Vous pouvez souscrire à trois types d'abonnements :
- Abonnements temporaires. Comme les collecteurs d'événements habituels, les abonnements temporaires sont liés à la durée de vie de l'instance d'objet. Quand l'objet abonné est libéré, l'abonnement s'arrête et COM+ ne lui transmet plus les événements.
- Abonnements permanents. Ils sont liés à la classe de l'objet et non à une instance d'objet spécifique. Quand l'événement se produit, COM recherche ou démarre un processus de l'objet abonné et appelle son gestionnaire d'événement. Les objets en processus (DLL) utilisent ce type d’abonnement.
- Abonnements par utilisateur. Ces abonnements offrent une version plus sécurisée des abonnements temporaires. L'objet abonné et l'objet serveur qui déclenchent les événements doivent être exécutés avec le même compte utilisateur sur la même machine.