Interagindo com o Spooler MAPI

Aplica-se a: Outlook 2013 | Outlook 2016

Os métodos na interface IXPLogon : IUnknown são usados pelo spooler MAPI ao chamar o provedor de transporte. Deve ser possível que a maioria dos tipos de provedores de transporte implemente a maioria desses métodos para que eles retornem rapidamente. Isso é desejável porque se um método demorar muito tempo para retornar, ele deve ser dividido com chamadas de volta para o carretel MAPI para liberar a CPU para outras tarefas.

O spooler MAPI faz seu trabalho e faz suas chamadas para provedores de transporte quando os aplicativos em primeiro plano estão ociosos. Depois de exibir opcionalmente caixas de diálogo quando o provedor de transporte é conectado pela primeira vez (regido por sinalizadores passados do MAPI para o provedor de transporte), os provedores de transporte operam em segundo plano, a menos que sejam chamados pelo cliente para liberar filas de envio e recebimento. A liberação de filas é a única vez que um provedor de transporte não precisa liberar a CPU e, em seguida, somente se o usuário for informado de que uma ação potencialmente longa está em andamento. O spooler MAPI normalmente solicita que um provedor de transporte libere suas filas em resposta a uma ação do usuário, portanto, o provedor de transporte normalmente não precisa fazer nada para garantir que o usuário seja informado.

Um provedor de transporte pode decidir, independentemente, liberar uma fila e usar os bits STATUS_INBOUND_FLUSH e STATUS_OUTBOUND_FLUSH na propriedade PR_STATUS_CODE (PidTagStatusCode) de sua linha status para informar ao spooler MAPI que ele quer atenção para que ele possa fazer o trabalho. A linha status é atualizada usando o método IMAPISupport::ModifiStatusRow. Nesse caso, o provedor de transporte provavelmente deve exibir um indicador de progresso ou outra interface para informar ao usuário que uma ação longa está ocorrendo.

Como a atividade de rede geralmente leva mais de 0,2 segundos, os provedores de transporte devem, sempre que possível, usar solicitações de rede assíncronas. Isso permite que eles iniciem uma solicitação, liberem a CPU chamando de volta para o spooler MAPI e, quando o spooler MAPI novamente lhes dá controle, para marcar para ver se a solicitação de rede foi concluída. Se ele ainda não tiver sido concluído, eles novamente liberarão a CPU chamando de volta para o spooler MAPI com o método IMAPISupport::SpoolerYield .

Durante o processamento de mensagens, entre IXPLogon::SubmitMessage e IXPLogon::EndMessage e durante IXPLogon::StartMessage, o provedor de transporte normalmente faz muitas chamadas em objetos expostos a ele pelo spooler MAPI. Como parte de seu tratamento desses objetos, o spooler MAPI ajuda o provedor de transporte a se comportar adequadamente como um processo em segundo plano, cedendo por conta própria quando apropriado. Um provedor de transporte que exige processamento crítico de tempo pode declarar uma seção crítica ao spooler MAPI usando o método de objeto de suporte IMAPISupport::SpoolerNotify . Nesse caso, a CPU é liberada somente em chamadas explícitas do SpoolerYield pelo provedor de transporte até que o provedor de transporte termine o processamento de seção crítica com outra chamada para SpoolerNotify.

Observação

Isso não é o mesmo que uma seção crítica do Win32. Isso só deve ser feito quando o provedor de transporte precisar de controle em tempo real de recursos externos, como ler dados de entrada de uma linha de fax. Como isso gera a prioridade do processo de spooler MAPI e pode fazer com que a estação de trabalho não responda durante a operação, é uma boa ideia notificar o usuário de que uma ação potencialmente longa está em andamento e fornecer um indicador de progresso, se possível.