Suporte IDispEventImpl
A classe de modelo IDispEventImpl pode ser usado para fornecer suporte a coletores de ponto de conexão em sua classe ATL.Um coletor de ponto de conexão permite que sua classe manipular eventos acionados dos objetos COM externos.Esses coletores de ponto de conexão são mapeados com um evento MAP coletor, fornecido pela sua classe.
Para implementar adequadamente um coletor de ponto de conexão para sua classe, você devem concluir as seguintes etapas:
Importar as bibliotecas de tipos para cada objeto externo
Declarar o IDispEventImpl interfaces
Declarar um evento MAP coletor
Avisar e unadvise os pontos de conexão
As etapas envolvidas na implementação de um coletor de ponto de conexão são realizadas modificando somente o arquivo de cabeçalho (. h) da sua classe.
Importando as bibliotecas de tipos
Para cada objeto cujos eventos você deseja manipular externo, você deve importar a biblioteca de tipos.Esta etapa define o s evento que pode ser manipulado e fornece informações que são usadas ao declarar o evento MAP coletor.The # Import diretiva pode ser usada para fazer isso.Adicionar o necessário #import linhas de diretivas para cada interface dispatch oferecerá suporte ao arquivo de cabeçalho (. h) de sua classe.
O exemplo a seguir importa a biblioteca de tipos de um servidor COM externo (MSCAL.Calendar.7):
#import "PROGID:MSCAL.Calendar.7" no_namespace, raw_interfaces_only
.gif "Observação") Observação: |
|---|
Você deve ter um separado #import demonstrativo para cada biblioteca de tipos externos que oferecerá suporte. |
Declarar interfaces IDispEventImpl
Agora que você importou as bibliotecas de tipos de cada interface de distribuição, é necessário declarar separado IDispEventImpl interfaces para cada interface dispatch externo. Modificar a declaração da sua classe adicionando um IDispEventImpl declaração de interface para cada objeto externo. Para obter mais informações sobre os parâmetros, consulte IDispEventImpl.
O seguinte código declara dois dissipadores de ponto de conexão, a DCalendarEvents interface, para o objeto COM implementado pela classe CMyCompositCtrl2:
public IDispEventImpl<IDC_CALENDAR1, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>,
public IDispEventImpl<IDC_CALENDAR2, CMyCompositCtrl2, &__uuidof(DCalendarEvents), &__uuidof(__MSACAL), 7, 0>
Declarando um coletor evento MAP
Em ordem para as notificações de evento deve ser tratado pelo funcionamento adequado, sua classe deve rotear cada evento para seu manipulador correto.Isso é obtido, declarando um MAP de coletor de eventos.
ATL fornece várias macros, BEGIN_SINK_MAP, END_SINK_MAP, and SINK_ENTRY_EX, que tornam esse mapeamento mais fácil.O formato padrão é o seguinte:
BEGIN_SINK_MAP(comClass)
SINK_ENTRY_EX(id, iid, dispid, func)
. . . //additional external event entries
END_SINK_MAP()
O exemplo a seguir declara um evento MAP coletor com dois evento manipuladores:
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()
A implementação está quase concluída.A última etapa aborda o aviso e unadvising das interfaces externas.
Avisando e Unadvising Interfaces IDispEventImpl
A etapa final é implementar um método que irá informar (ou unadvise) todos os pontos de conexão em momentos apropriados.Este aconselhar deve ser concluído antes que a comunicação entre clientes externos e seu objeto possa ocorrer.Antes de seu objeto se torna visível, cada interface dispatch externo suportado pelo seu objeto é consultada para interfaces de saída.Uma conexão é estabelecida e uma referência para a interface de saída é usada para manipular eventos do objeto.Esse procedimento é conhecido sistema autônomo "aconselhar."
Depois que seu objeto termina com as interfaces externas, as interfaces de saída devem ser notificadas de que eles não são mais usados por sua classe.Esse processo é conhecido sistema autônomo "unadvising."
Devido à natureza exclusiva de objetos COM, esse procedimento varia em detalhes e execução entre implementações.Esses detalhes estão além do escopo deste tópico e não são abordadas.