IMessageFilter
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
9/8/2008
Essa interface fornece COM servidores e aplicativos a capacidade para seletivamente identificador de entrada e de saída COM mensagens enquanto aguarda as respostas dos síncrono chamadas.
Filtrando mensagens ajuda a garantir que chamadas são tratadas de maneira que melhora desempenho e evita bloqueios. COM mensagens podem ser síncrono, assíncrono ou entrada-sincronizado; a maioria da interface chamadas síncrono.
Chamadas síncronas requerem o chamador para aguardar uma resposta antes de continuar. COM insere um restrito executar um loop enquanto aguardava a resposta. Durante esse tempo, o chamador é ainda capaz de receber e distribuir de entrada mensagens.
O chamador para permitem chamadas assíncronas proceder sem aguardar uma resposta a partir de chamado objeto. Hoje, em COM, o único assíncrono chamadas são para do um objeto IAdviseSink interface. Enquanto o objeto é processamento de chamada assíncrona, ele é proibido de fazer qualquer síncrono chamadas voltar para o objeto de chamada.
Entrada-sincronizado chamadas exigem o chamado objeto para completo a chamar antes de abandonar controle, garantindo que comportamentos, como gerenciamento foco e função TYPE-Ahead corretamente.
Quando a implementar
Você provavelmente desejar para implementar seu próprio filtro mensagem. A implementação usar como padrão fornecida pelo COM oferece apenas mensagem mínimo filtragem funcionalidade.
Embora filtragem mensagem não seja tão significativo como estava com 16-bit aplicativos, porque o tamanho do fila de mensagens é agora praticamente ilimitado, você ainda deve implementar IMessageFilter Como uma maneira de resolver bloqueios.
COM irá chamar sua implementação de IMessageFilter Para localizar se um aplicativo é bloqueio, para que você possa tarefa-alternar para esse aplicativo e fornecem o usuário uma oportunidade para lidar com a situação.
De exemplo, se você tiver Microsoft Word falando para Microsoft Excel, com Excel execução no segundo plano na fórmula na qual as fórmulas estão sendo aplicadas ao dados sobre a planilha para calcular diferente ou que se resultados, será Excel não verificar todas chama, assim, modo bloqueio mais ação.
IMessageFilter poderia pôr até uma caixa diálogo indicando qual tarefa foi bloqueio e fornecer o usuário a uma oportunidade para lidar com o bloqueio.
Lembre-se de que HandleIncomingCall é um método Object-Based e RetryRejectedCall e MessagePending são métodos baseadas no cliente. O objeto deve ter alguma forma de manipulação de entrada chamadas de externo clientes. HandleIncomingCall fornece essa funcionalidade, permitindo que o objeto ao identificador ou adiar alguns de entrada chama e rejeitar outras pessoas.
O cliente também precisa saber como um objeto for identificador seu chamar. de forma que ele pode responder de forma apropriada. O cliente precisa saber se um chamar tem foi rejeitado, ou apenas adiada temporariamente, de modo que ele pode repetir rejeitada chamadas após alguns especificado tempo.
O cliente também precisa ser capaz de responder às mensagens Windows, enquanto no mesmo tempo aguardando respostas para pendente mensagens.
Você usará CoRegisterMessageFilter Para registrar seu filtro mensagem. Depois registrado, COM, em seguida, chama o filtro de mensagem instead of a implementação usar como padrão.
Quando usar
Não chamar diretamente essa interface. Ele é fornecido pelo servidor COM ou aplicativo e chamado pelo COM.
Desligamento do aplicativo COM WM_QUERYENDSESSION e WM_ENDSESSION
Quando um usuário sai Windows, cada aberto aplicativo recebe uma mensagem WM_QUERYENDSESSION seguida por uma mensagem WM_ENDSESSION, desde a sair não é cancelado.
Essas mensagens são chamadas com SendMessage, que infelizmente restringe o início da de saída todas as chamadas LRPC. Este é um problema para aplicativos contêiner que tenham aberto incorporado objetos ao receberem a solicitação desligamento porque o LRPC é necessária para fechar esses objetos.
Recipiente e contêiner/aplicativos servidor COM aberto documentos geralmente exibir uma caixa mensagem ao receber a mensagem WM_QUERYENDSESSION que pergunta se o usuário deseja salvar as alterações antes de sair. Normalmente o padrão é uma resposta positiva.
Para lidar com essa situação, considere ter a exibir aplicativo um alternativo caixa mensagem perguntando se o usuário deseja descartar as alterações; Uma resposta negativa deve ser a usar como padrão.
Se o usuário escolher para descartar as alterações, TRUE deve ser retornado para WM_QUERYENDSESSION, qual sinaliza ao Windows que ela pode finalizar.
Se o usuário não desejar para descartar as alterações, FALSE deve ser retornado.
Nenhuma tentativa deve ser feita para fechar ou versão execução embeddings.
Aplicativos de servidor devem retornar TRUE para WM_QUERYENDSESSION sem avisar o usuário. No recebimento de uma mensagem WM_ENDSESSION, todos os aplicativos COM devem executar o padrão fechar seqüência para documentos de cada aplicativo e / ou objetos.
No mesmo tempo, você deve ignorar erros resultantes da cruzado-processo chama ou chamadas para Lançamento.
(Todos os ponteiros armazenamentoIStorage e IStream Ponteiros interface) devem ser lançados para corretamente liberado arquivos temporários mantidos pela implementação arquivo composto de armazenamento estruturado.
Métodos na ordem TabelaV
| Método IUnknown | Descrição |
|---|---|
Retorna os ponteiros para com suporte interfaces. |
|
Incrementa a contagem de referência. |
|
Diminui o contagem de referência. |
| Método | Descrição |
|---|---|
Provides a single entry point for incoming calls. |
|
Fornece aplicativo oportunidade para exibir uma caixa diálogo oferecendo Tente novamente ou cancelar ou tarefa alternando opções. |
|
Indica uma mensagem Windows chegou enquanto COM está aguardando para responder a um remoto chamar. |
Remarks
Para determinar se a plataforma oferece suporte a esta interface, consulte Determinando suporte COM APIs.
Requisitos
| Header | objidl.h, objidl.idl |
| Library | ole32.lib, uuid.lib |
| Windows Embedded CE | Windows CE 3.0 and later |
| Windows Mobile | Windows Mobile Version 5.0 and later |