Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Nota
La libreria di modelli attivi (ATL) continua a essere supportata. Tuttavia, non aggiungiamo più funzionalità né aggiorniamo la documentazione.
La classe template IDispEventImpl può essere usata per fornire supporto per i sinc dei punti di connessione nella classe ATL. Un sink del punto di connessione consente alla classe di gestire gli eventi generati da oggetti COM esterni. Questi sink dei punti di connessione vengono mappati a una mappa di sink eventi, fornita dalla tua classe.
Per implementare correttamente un sink del punto di connessione per la tua classe, è necessario completare i seguenti passaggi:
Importare le librerie dei tipi per ogni oggetto esterno
Dichiarare le
IDispEventImplinterfacceDichiarare una mappa di gestione eventi
Consigliare e annullare la visualizzazione dei punti di connessione
I passaggi necessari per implementare un connection point sink vengono eseguiti modificando solo il file header (.h) della tua classe.
Importazione delle librerie di tipo
Per ogni oggetto esterno di cui si desidera gestire gli eventi, è necessario importare la libreria dei tipi. Questo passaggio definisce gli eventi che possono essere gestiti e fornisce informazioni usate nel dichiarare la mappa di gestione degli eventi. A tale scopo, è possibile usare la direttiva #import . Aggiungere le righe di direttiva #import necessarie per ogni interfaccia di dispatch che si desidera supportare nel file di intestazione (.h) della classe.
Nell'esempio seguente viene importata la libreria dei tipi di un server COM esterno (MSCAL.Calendar.7):
#import "PROGID:MSCAL.Calendar.7" no_namespace, raw_interfaces_only
Nota
È necessario disporre di un'istruzione separata #import per ciascuna libreria dei tipi esterna che vuoi supportare.
Dichiarazione delle interfacce IDispEventImpl
Ora che sono state importate le librerie dei tipi di ogni interfaccia dispatch, è necessario dichiarare interfacce separate IDispEventImpl per ogni interfaccia dispatch esterna. Modificare la dichiarazione della classe aggiungendo una IDispEventImpl dichiarazione di interfaccia per ogni oggetto esterno. Per altre informazioni sui parametri, vedere IDispEventImpl.
Il codice seguente dichiara due sink del punto di connessione, per l'interfaccia DCalendarEvents, per l'oggetto COM implementato dalla classe CMyCompositCtrl2.
public IDispEventImpl<IDC_CALENDAR1, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>,
public IDispEventImpl<IDC_CALENDAR2, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>
Dichiarazione di una mappa sink di eventi
Affinché le notifiche degli eventi vengano gestite dalla funzione corretta, la classe deve instradare ogni evento al gestore corretto. Questa operazione viene ottenuta dichiarando una mappa del sink di eventi.
ATL offre diverse macro, BEGIN_SINK_MAP, END_SINK_MAP e SINK_ENTRY_EX, che semplificano questo mapping. Il formato standard è il seguente:
BEGIN_SINK_MAP(comClass)
SINK_ENTRY_EX(id, iid, dispid, func)
. . . //additional external event entries
END_SINK_MAP()
L'esempio seguente dichiara una mappa sink di eventi con due gestori eventi:
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'implementazione è quasi completa. L'ultimo passaggio riguarda la notifica e l'annullamento di notifiche delle interfacce esterne.
Consigli e rinuncia alle interfacce IDispEventImpl
Il passaggio finale consiste nell'implementare un metodo che consiglia (o non avvisa) tutti i punti di connessione nei momenti appropriati. Questo avviso deve essere fatto prima che possa avvenire la comunicazione tra i client esterni e il vostro oggetto. Prima che l'oggetto diventi visibile, viene eseguita una query su ogni interfaccia dispatch esterna supportata dall'oggetto per le interfacce in uscita. Viene stabilita una connessione e viene usato un riferimento all'interfaccia in uscita per gestire gli eventi dall'oggetto . Questa procedura viene definita "consulenza".
Una volta che il tuo oggetto ha terminato con le interfacce esterne, le interfacce in uscita devono essere informate che la tua classe non le utilizza più. Questo processo è noto come "unadvising".
A causa della natura univoca degli oggetti COM, questa procedura varia, in dettaglio ed esecuzione, tra le implementazioni. Questi dettagli non rientrano nell'ambito di questo argomento e non vengono trattati.