Interface IMessageFilter (objidl.h)

Fornece aos servidores e aplicativos COM a capacidade de lidar seletivamente com mensagens COM de entrada e saída enquanto aguarda respostas de chamadas síncronas. Filtrar mensagens ajuda a garantir que as chamadas sejam tratadas de uma maneira que melhore o desempenho e evite deadlocks. As mensagens COM podem ser síncronas, assíncronas ou sincronizadas com entrada; a maioria das chamadas de interface são síncronas.

Herança

A interface IMessageFilter herda da interface IUnknown . IMessageFilter também tem estes tipos de membros:

Métodos

A interface IMessageFilter tem esses métodos.

IMessageFilter::HandleInComingCall Fornece um único ponto de entrada para chamadas de entrada.
IMessageFilter::MessagePending Indica que uma mensagem chegou enquanto COM está esperando para responder a uma chamada remota.
IMessageFilter::RetryRejectedCall Fornece aos aplicativos a oportunidade de exibir uma caixa de diálogo que oferece opções de repetição, cancelamento ou troca de tarefas.

Comentários

Chamadas síncronas exigem que o chamador aguarde uma resposta antes de continuar. COM insere um loop modal enquanto aguarda a resposta. Durante esse tempo, o chamador ainda poderá receber e expedir mensagens de entrada.

Chamadas assíncronas permitem que o chamador prossiga sem aguardar uma resposta do objeto chamado. Hoje, no COM, as únicas chamadas assíncronas são para a interface IAdviseSink de um objeto. Embora o objeto esteja processando uma chamada assíncrona, ele é proibido de fazer chamadas síncronas de volta para o objeto de chamada.

Para habilitar comportamentos como gerenciamento de foco e type-ahead para funcionar corretamente, as chamadas sincronizadas por entrada exigem que o objeto chamado conclua a chamada antes de abrir mão do controle.

Desligamento do aplicativo com WM_QUERYENDSESSION e WM_ENDSESSION

Quando um usuário sai do Windows, cada aplicativo aberto recebe uma mensagem WM_QUERYENDSESSION seguida por uma mensagem WM_ENDSESSION , desde que a saída não seja cancelada. Essas mensagens são invocadas com a função SendMessage , que infelizmente restringe o início de todas as chamadas LRPC de saída. Esse é um problema para aplicativos de contêiner que têm objetos inseridos abertos quando recebem a solicitação de desligamento porque o LRPC é necessário para fechar esses objetos.

Aplicativos de contêiner e contêiner/servidor com documentos abertos normalmente exibem uma caixa de mensagem no recebimento da mensagem de WM_QUERYENDSESSION que pergunta se o usuário deseja salvar as alterações antes de sair. Uma resposta positiva geralmente é o padrão. A recomendação para lidar com a situação descrita acima é que o aplicativo exiba uma caixa de mensagem alternativa perguntando se o usuário deseja descartar alterações; uma resposta negativa deve ser o padrão. Se o usuário optar por descartar as alterações, TRUE deverá ser retornado para WM_QUERYENDSESSION, o que sinaliza para o Windows que ele pode terminar. Se o usuário não quiser descartar as alterações, FALSE deverá ser retornado. Nenhuma tentativa deve ser feita para fechar ou liberar incorporações em execução.

Os aplicativos de servidor devem retornar TRUE para WM_QUERYENDSESSION sem avisar o usuário. Ao receber uma mensagem WM_ENDSESSION , todos os aplicativos COM devem executar a sequência de fechamento normal para os documentos e objetos de cada aplicativo. Ao mesmo tempo, você deve ignorar quaisquer erros resultantes de chamadas ou chamadas entre processos para IUnknown::Release. Todos os ponteiros de armazenamento (ponteiros de interface IStorage e IStream ) devem ser liberados para liberar corretamente todos os arquivos temporários mantidos pela implementação de arquivo composto do armazenamento estruturado.

Requisitos

Requisito	Valor
Cliente mínimo com suporte	Windows 2000 Professional [somente aplicativos da área de trabalho]
Servidor mínimo com suporte	Windows 2000 Server [somente aplicativos da área de trabalho]
Plataforma de Destino	Windows
Cabeçalho	objidl.h