IXPLogon::TransportNotify
Aplica-se a: Outlook 2013 | Outlook 2016
Sinaliza a ocorrência de um evento sobre o qual o provedor de transporte solicitou a notificação.
HRESULT TransportNotify(
ULONG FAR * lpulFlags,
LPVOID FAR * lppvData
);
Parâmetros
lpulFlags
[in, out] Um bitmask de sinalizadores que sinaliza eventos de notificação. Os seguintes sinalizadores podem ser definidos pelo spooler MAPI na entrada e devem ser retornados inalterados na saída:
NOTIFY_ABORT_DEFERRED
Notifica o provedor de transporte de que uma mensagem para a qual ele aceitou a responsabilidade está sendo adiada. Somente os provedores de transporte que dão suporte ao adiamento devem dar suporte a esse sinalizador. O parâmetro lppvData aponta para o identificador de entrada da mensagem cancelada. As mensagens que o spooler MAPI não processou ainda podem ser adiadas chamando o método IMsgStore::AbortSubmit .
NOTIFY_BEGIN_INBOUND
O spooler MAPI agora pode aceitar mensagens de entrada para esta sessão do provedor de transporte. O spooler MAPI chama regularmente o método IXPLogon::P oll se o provedor de transporte definir o sinalizador LOGON_SP_POLL com a chamada IXPProvider::TransportLogon no logon. Depois que o sinalizador NOTIFY_BEGIN_INBOUND for definido, o carreador MAPI honrará o sinalizador NOTIFY_NEWMAIL passado na chamada para o método IMAPISupport::SpoolerNotify . A linha de tabela status para a sessão do provedor de transporte deve ser atualizada antes de retornar chamando o método IMAPISupport::ModifiStatusRow. Os sinalizadores NOTIFY_BEGIN_INBOUND e NOTIFY_END_INBOUND são mutuamente exclusivos.
NOTIFY_BEGIN_INBOUND_FLUSH
Sinaliza o provedor de transporte para percorrer mensagens de entrada o mais rápido possível. Para cumprir essa notificação, o provedor de transporte deve definir o sinalizador STATUS_INBOUND_FLUSH na propriedade PR_STATUS_CODE (PidTagStatusCode) de sua linha de tabela status assim que puder, usando ModifiStatusRow. Um ciclo de mensagens de entrada é concluído quando o provedor determina que ele baixou tudo o que pode ou quando recebeu uma chamada de método TransportNotify com o conjunto de sinalizadores NOTIFY_END_INBOUND_FLUSH. Até o final do ciclo de mensagens de entrada, o provedor não deve chamar o método IMAPISupport::SpoolerYield ou abrir mão de ciclos para o sistema operacional para acelerar a entrega de mensagens de entrada. Isso é aceitável porque o spooler MAPI normalmente usa NOTIFY_BEGIN_INBOUND_FLUSH apenas em resposta à solicitação de um usuário, por meio de um aplicativo cliente, para entregar todas as mensagens agora. No final da operação de liberação de entrada, o provedor deve usar o SpoolerNotify para limpar o sinalizador de STATUS_INBOUND_FLUSH na propriedade PR_STATUS_CODE de sua linha status.
NOTIFY_BEGIN_OUTBOUND
As operações de saída agora podem ocorrer para esta sessão do provedor de transporte. Se houver mensagens a serem enviadas para esse provedor, uma chamada para o método IXPLogon::SubmitMessage será seguida. A linha de tabela status para esta sessão deve ser atualizada antes de retornar. Os sinalizadores NOTIFY_BEGIN_OUTBOUND e NOTIFY_END_OUTBOUND são mutuamente exclusivos.
NOTIFY_BEGIN_OUTBOUND_FLUSH
Funciona de forma semelhante ao sinalizador NOTIFY_BEGIN_INBOUND_FLUSH, mas refere-se a mensagens de saída. O sinalizador de status apropriado é STATUS_OUTBOUND_FLUSH.
NOTIFY_CANCEL_MESSAGE
O spooler MAPI deve cancelar a transferência da mensagem para a qual o parâmetro lppvData aponta para o valor de 32 bits da chamada do método IXPLogon::SubmitMessage . O sinalizador NOTIFY_CANCEL_MESSAGE pode ser definido sem que o provedor de transporte tenha retornado da chamada de método SubmitMessage, IXPLogon::StartMessage ou IXPLogon::EndMessage associada à mensagem. O provedor de transporte deve retornar o mais rápido possível do ponto de entrada que está lidando com a mensagem cancelada. Para uma mensagem de entrada que está sendo processada no momento, o provedor de transporte deve salvar a mensagem de entrada onde quer que ela esteja armazenada atualmente e entregá-la novamente na próxima hora conveniente. Os dados do objeto de mensagem já armazenados para a mensagem de entrada são descartados. Se o provedor de transporte não atualizou esse valor de 32 bits na hora StartMessage ou SubmitMessage , o valor será 0 para mensagens de saída e 1 para mensagens de entrada.
NOTIFY_END_INBOUND
As operações de entrada devem cessar para esta sessão do provedor de transporte. O spooler MAPI deixa de usar o método Poll e ignora NOTIFY_NEWMAIL para esta sessão. As mensagens em processo devem ser concluídas. A linha de tabela status para a sessão de transporte deve ser atualizada chamando ModifiStatusRow antes de retornar. Os sinalizadores NOTIFY_END_INBOUND e NOTIFY_BEGIN_INBOUND são mutuamente exclusivos.
NOTIFY_END_INBOUND_FLUSH
Notifica o provedor de transporte a sair do modo de liberação de entrada. O provedor de transporte não deve parar de baixar, mas o download deve ser feito em segundo plano. A linha de tabela status para a sessão de transporte deve ser atualizada chamando ModifiStatusRow quando o provedor de transporte puder cumprir essa notificação.
NOTIFY_END_OUTBOUND
As operações de saída devem cessar para esta sessão do provedor de transporte. O spooler MAPI deixa de chamar SubmitMessage e ignora o sinalizador SpoolerNotify NOTIFY_READYTOSEND. Se houver uma mensagem de saída sendo enviada no momento, ela não deverá ser interrompida; para interromper a entrega de uma mensagem, use o sinalizador NOTIFY_CANCEL_MESSAGE. A linha de tabela status para esta sessão deve ser atualizada chamando ModifiStatusRow antes de retornar. Os sinalizadores NOTIFY_END_INBOUND e NOTIFY_BEGIN_OUTBOUND são mutuamente exclusivos.
NOTIFY_END_OUTBOUND_FLUSH
Funciona de forma semelhante à NOTIFY_END_INBOUND_FLUSH, mas refere-se a mensagens de saída. O sinalizador de status apropriado é STATUS_OUTBOUND_FLUSH.
lppvData
[out] Um ponteiro para um ponteiro para dados específicos do evento. Para obter mais informações sobre o que lppvData especifica, consulte a descrição do parâmetro lpulFlags .
Valor de retorno
S_OK
A chamada foi bem-sucedida e retornou o valor ou valores esperados.
Comentários
O spooler MAPI chama o método IXPLogon::TransportNotify para sinalizar o provedor de transporte sobre os eventos para os quais a notificação foi solicitada. Esses eventos incluem uma solicitação de spooler MAPI para cancelar uma transferência de mensagem, o início ou o término das operações de transporte de entrada ou saída e o início ou término de uma operação para limpar uma fila de mensagens de entrada ou de saída.
Quando o usuário tenta cancelar uma mensagem que o provedor de transporte adiou anteriormente, o spooler MAPI chama TransportNotify, passando os sinalizadores NOTIFY_ABORT_DEFERRED e NOTIFY_CANCEL_MESSAGE em ulFlags. Se o spooler MAPI estiver fazendo logon e ainda tiver mensagens na fila, ele passará apenas NOTIFY_ABORT_DEFERRED em ulFlags quando chama TransportNotify.
Observações para implementadores
O provedor deve sincronizar o acesso aos seus dados nesta chamada, pois o spooler MAPI pode invocar esse método de outro thread de execução ou de um procedimento para uma janela diferente. Isso provavelmente ocorrerá quando o spooler MAPI sinalizar o cancelamento de uma mensagem que o provedor de transporte começou a enviar.