Partager via


Prise en charge d’IDispEventImpl

Remarque

La bibliothèque de modèles actifs (ATL) continue d’être prise en charge. Toutefois, nous n’ajoutons plus de fonctionnalités ni ne mettons à jour la documentation.

La classe de modèle IDispEventImpl peut être utilisée pour prendre en charge les récepteurs de point de connexion dans votre classe ATL. Un récepteur de points de connexion permet à votre classe de gérer les événements déclenchés à partir d’objets COM externes. Ces récepteurs de points de connexion sont associés à une cartographie de récepteurs d'événements, fournie par votre classe.

Pour implémenter correctement un récepteur de point de connexion pour votre classe, les étapes suivantes doivent être effectuées :

  • Importer les bibliothèques de types pour chaque objet externe

  • Déclarer les IDispEventImpl interfaces

  • Déclarer un mappage récepteur d’événements

  • Établir et supprimer les points de connexion

Les étapes impliquées dans l’implémentation d’un récepteur de point de connexion sont toutes effectuées en modifiant uniquement le fichier d’en-tête (.h) de votre classe.

Importation des bibliothèques de types

Pour chaque objet externe dont vous souhaitez gérer les événements, vous devez importer la bibliothèque de types. Cette étape définit les événements qui peuvent être gérés et fournit des informations utilisées lors de la déclaration de la carte de capture d'événements. La directive #import peut être utilisée pour ce faire. Ajoutez les lignes de directive nécessaires #import pour chaque interface de distribution que vous prendrez en charge dans le fichier d’en-tête (.h) de votre classe.

L’exemple suivant importe la bibliothèque de types d’un serveur COM externe (MSCAL.Calendar.7) :

#import "PROGID:MSCAL.Calendar.7" no_namespace, raw_interfaces_only

Remarque

Vous devez disposer d’une instruction distincte #import pour chaque bibliothèque de types externe que vous prendrez en charge.

Déclaration des interfaces IDispEventImpl

Maintenant que vous avez importé les bibliothèques de types de chaque interface de distribution, vous devez déclarer des interfaces distinctes IDispEventImpl pour chaque interface de répartition externe. Modifiez la déclaration de votre classe en ajoutant une déclaration d’interface IDispEventImpl pour chaque objet externe. Pour plus d’informations sur les paramètres, consultez IDispEventImpl.

Le code suivant déclare deux points de réception de connexion pour l'interface DCalendarEvents, pour l'objet COM implémenté par la classe CMyCompositCtrl2.

public IDispEventImpl<IDC_CALENDAR1, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>,
public IDispEventImpl<IDC_CALENDAR2, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>

Déclaration d’un mappage récepteur d’événements

Pour que les notifications d’événements soient gérées par la fonction appropriée, votre classe doit acheminer chaque événement vers son gestionnaire correct. Pour ce faire, déclarez un plan de récepteur d'événements.

ATL fournit plusieurs macros, BEGIN_SINK_MAP, END_SINK_MAP et SINK_ENTRY_EX, ce qui facilite ce mappage. Le format standard est le suivant :

BEGIN_SINK_MAP(comClass)
  SINK_ENTRY_EX(id, iid, dispid, func)
  . . . //additional external event entries
END_SINK_MAP()

L’exemple suivant déclare une carte de récepteurs d’événements avec deux gestionnaires d’événements :

BEGIN_SINK_MAP(CMyCompositCtrl2)
   //Make sure the Event Handlers have __stdcall calling convention
   SINK_ENTRY_EX(IDC_CALENDAR1, __uuidof(DCalendarEvents), DISPID_CLICK, 
      &CMyCompositCtrl2::ClickCalendar1)
   SINK_ENTRY_EX(IDC_CALENDAR2, __uuidof(DCalendarEvents), DISPID_CLICK, 
      &CMyCompositCtrl2::ClickCalendar2)
END_SINK_MAP()

L’implémentation est presque terminée. La dernière étape concerne l'activation et la désactivation des interfaces externes.

Enregistrement et désenregistrement des interfaces IDispEventImpl

La dernière étape consiste à implémenter une méthode qui ajuste (ou désajuste) tous les points de connexion au bon moment. Ce conseil doit être effectué avant la communication entre les clients externes et votre objet. Avant que votre objet ne devienne visible, chaque interface de répartition externe prise en charge par votre objet est interrogée pour les interfaces sortantes. Une connexion est établie et une référence à l’interface sortante est utilisée pour gérer les événements de l’objet. Cette procédure est appelée « conseil ».

Une fois votre objet terminé avec les interfaces externes, les interfaces sortantes doivent être averties qu’elles ne sont plus utilisées par votre classe. Ce processus est appelé « non supervisé ».

En raison de la nature unique des objets COM, cette procédure varie, en détail et en exécution, entre les implémentations. Ces détails dépassent la portée de cette rubrique et ne sont pas traités.

Voir aussi

Principes de base des objets ATL COM