Classe ECLStartNotify

ECLStartNotify est une classe de base abstraite. Une application ne peut pas créer directement une instance de cette classe. Pour utiliser cette classe, l'application doit définir sa propre classe dérivée d'ECLStartNotify. L'application doit implémenter la fonction membre NotifyEvent() dans sa classe dérivée. Elle peut également éventuellement implémenter les fonctions membres NotifyError() et NotifyStop().

La classe ECLSartNotify est utilisée pour permettre à une application d'être notifiée du démarrage et de l'arrêt des connexions ZIEWin. Les événements de démarrage/arrêt sont générés chaque fois qu'une connexion ZIEWin (fenêtre) est démarrée ou arrêtée par tout moyen, y compris les méthodes de démarrage/arrêt ECLConnMgr.

L'exemple présenté montre comment cela peut être réalisé. Une fois les étapes ci-dessus terminées, chaque fois qu'une connexion est démarrée ou arrêtée, la fonction membre NotifyEvent() de l'application sera appelée. La fonction reçoit deux paramètres donnant le descripteur de la connexion et un indicateur de démarrage/arrêt BOOL. L'application peut exécuter toutes les fonctions requises dans la procédure NotifyEvent(), y compris l'appel d'autres fonctions ECL. Notez que l'application ne peut pas empêcher l'arrêt d'une connexion. La notification est effectuée après l'arrêt de la session.

Si une erreur est détectée lors de la génération d'un événement, la fonction membre NotifyError() est appelée avec un objet ECLErr. Les événements peuvent ou non continuer à être générés après une erreur, selon la nature de l'erreur. Lorsque la génération d'événements se termine (soit en raison d'une erreur, en appelant ECLConnMgr::UnregisterStartEvent, soit par destruction de l'objet ECLConnMgr), la fonction membre NotifyStop() est appelée. Quelle que soit la manière dont la notification d'événement est terminée, la fonction membre NotifyStop() est toujours appelée et l'objet application n'est pas enregistré.

Si l'application ne fournit pas d'implémentation de la fonction membre NotifyError(), l'implémentation par défaut est utilisée (une simple boîte de message s'affiche à l'utilisateur). L'application peut remplacer le comportement par défaut en implémentant la fonction NotifyError() dans la classe dérivée de l'application. De même, la fonction NotifyStop() par défaut est utilisée si l'application ne fournit pas cette fonction (le comportement par défaut est de ne rien faire).

Notez que l'application peut également choisir de fournir ses propres constructeur et destructeur pour la classe dérivée. Cela peut être utile si l'application souhaite stocker des données spécifiques à l'instance dans la classe et transmettre ces informations en tant que paramètre au constructeur. Par exemple, l'application peut souhaiter publier un message dans une fenêtre d'application lorsqu'un événement de démarrage/arrêt se produit. Plutôt que de définir le descripteur de la fenêtre en tant que variable globale (afin qu'il soit visible par la fonction NotifyEvent()), l'application peut définir un constructeur pour la classe qui prend le descripteur de la fenêtre et le stocke dans la zone de données du membre de la classe.

L'application ne doit pas détruire l'objet de notification alors qu'il est enregistré pour recevoir des événements.

Restriction d'implémentation : actuellement, l'objet ECLConnMgr autorise l'enregistrement d'un seul objet de notification pour une notification d'événement de démarrage/arrêt. ECLConnMgr::RegisterStartEvent générera une erreur si un objet de notification est déjà enregistré pour cet objet ECLConnMgr.