IXPLogon::TransportNotify
Gilt für: Outlook 2013 | Outlook 2016
Signalisiert das Auftreten eines Ereignisses, über das der Transportanbieter eine Benachrichtigung angefordert hat.
HRESULT TransportNotify(
ULONG FAR * lpulFlags,
LPVOID FAR * lppvData
);
Parameter
lpulFlags
[in, out] Eine Bitmaske von Flags, die Benachrichtigungsereignisse signalisiert. Die folgenden Flags können vom MAPI-Spooler bei der Eingabe festgelegt werden und müssen unverändert bei der Ausgabe zurückgegeben werden:
NOTIFY_ABORT_DEFERRED
Benachrichtigt den Transportanbieter darüber, dass eine Nachricht, für die er die Verantwortung übernommen hat, zurückgestellt wird. Nur Transportanbieter, die die Verzögerung unterstützen, müssen dieses Flag unterstützen. Der lppvData-Parameter verweist auf den Eintragsbezeichner der abgebrochenen Nachricht. Nachrichten, die der MAPI-Spooler nicht verarbeitet hat, können weiterhin durch Aufrufen der IMsgStore::AbortSubmit-Methode zurückgestellt werden.
NOTIFY_BEGIN_INBOUND
Der MAPI-Spooler kann nun eingehende Nachrichten für diese Transportanbietersitzung akzeptieren. Der MAPI-Spooler ruft regelmäßig die IXPLogon::P oll-Methode auf, wenn der Transportanbieter das LOGON_SP_POLL-Flag mit dem IXPProvider::TransportLogon-Aufruf bei der Anmeldung festgelegt hat. Sobald das NOTIFY_BEGIN_INBOUND-Flag festgelegt ist, berücksichtigt der MAPI-Spooler das NOTIFY_NEWMAIL Flag, das im Aufruf der IMAPISupport::SpoolerNotify-Methode übergeben wurde. Die status Tabellenzeile für die Transportanbietersitzung sollte vor der Rückgabe durch Aufrufen der IMAPISupport::ModifyStatusRow-Methode aktualisiert werden. Die flags NOTIFY_BEGIN_INBOUND und NOTIFY_END_INBOUND schließen sich gegenseitig aus.
NOTIFY_BEGIN_INBOUND_FLUSH
Signalisiert dem Transportanbieter, so schnell wie möglich eingehende Nachrichten zu durchlaufen. Um diese Benachrichtigung einzuhalten, sollte der Transportanbieter das STATUS_INBOUND_FLUSH-Flag in der eigenschaft PR_STATUS_CODE (PidTagStatusCode) seiner status Tabellenzeile so schnell wie möglich mithilfe von ModifyStatusRow festlegen. Ein eingehender Messagingzyklus ist abgeschlossen, wenn der Anbieter feststellt, dass er alles heruntergeladen hat, was er kann, oder wenn er einen TransportNotify-Methodenaufruf mit festgelegtem NOTIFY_END_INBOUND_FLUSH-Flag empfangen hat. Bis zum Ende des eingehenden Messagingzyklus sollte der Anbieter die IMAPISupport::SpoolerYield-Methode nicht aufrufen oder anderweitig Zyklen an das Betriebssystem abgeben, um die Übermittlung eingehender Nachrichten zu beschleunigen. Dies ist akzeptabel, da der MAPI-Spooler in der Regel NOTIFY_BEGIN_INBOUND_FLUSH nur als Reaktion auf die Anforderung eines Benutzers über eine Clientanwendung verwendet, um alle Nachrichten jetzt zu übermitteln. Am Ende des eingehenden Leerungsvorgangs sollte der Anbieter SpoolerNotify verwenden, um das STATUS_INBOUND_FLUSH-Flag in der PR_STATUS_CODE-Eigenschaft seiner status Zeile zu löschen.
NOTIFY_BEGIN_OUTBOUND
Ausgehende Vorgänge können jetzt für diese Transportanbietersitzung ausgeführt werden. Wenn nachrichten vorhanden sind, die für diesen Anbieter gesendet werden sollen, folgt ein Aufruf der IXPLogon::SubmitMessage-Methode . Die status Tabellenzeile für diese Sitzung sollte vor der Rückgabe aktualisiert werden. Die flags NOTIFY_BEGIN_OUTBOUND und NOTIFY_END_OUTBOUND schließen sich gegenseitig aus.
NOTIFY_BEGIN_OUTBOUND_FLUSH
Funktioniert ähnlich wie das NOTIFY_BEGIN_INBOUND_FLUSH-Flag, bezieht sich jedoch auf ausgehende Nachrichten. Das entsprechende status-Flag ist STATUS_OUTBOUND_FLUSH.
NOTIFY_CANCEL_MESSAGE
Der MAPI-Spooler muss die Übertragung der Nachricht abbrechen, für die der lppvData-Parameter auf den 32-Bit-Wert aus dem IXPLogon::SubmitMessage-Methodenaufruf verweist. Das NOTIFY_CANCEL_MESSAGE-Flag kann festgelegt werden, ohne dass der Transportanbieter aus dem SubmitMessage-, IXPLogon::StartMessage- oder IXPLogon::EndMessage-Methodenaufruf zurückgegeben wurde, der der Nachricht zugeordnet ist. Der Transportanbieter muss so bald wie möglich vom Einstiegspunkt zurückkehren, der die abgebrochene Nachricht verarbeitet. Bei einer eingehenden Nachricht, die gerade verarbeitet wird, sollte der Transportanbieter die eingehende Nachricht dort speichern, wo sie derzeit gespeichert ist, und sie zum nächsten geeigneten Zeitpunkt erneut übermitteln. Die bereits für die eingehende Nachricht gespeicherten Nachrichtenobjektdaten werden verworfen. Wenn der Transportanbieter diesen 32-Bit-Wert nicht zum StartMessage - oder SubmitMessage-Zeitpunkt aktualisiert hat, ist der Wert 0 für ausgehende Nachrichten und 1 für eingehende Nachrichten.
NOTIFY_END_INBOUND
Eingehende Vorgänge müssen für diese Transportanbietersitzung beendet werden. Der MAPI-Spooler verwendet nicht mehr die Poll-Methode und ignoriert NOTIFY_NEWMAIL für diese Sitzung. In-Process-Meldungen sollten abgeschlossen werden. Die status Tabellenzeile für die Transportsitzung sollte aktualisiert werden, indem ModifyStatusRow vor der Rückgabe aufgerufen wird. Die flags NOTIFY_END_INBOUND und NOTIFY_BEGIN_INBOUND schließen sich gegenseitig aus.
NOTIFY_END_INBOUND_FLUSH
Benachrichtigt den Transportanbieter, dass er den Eingehenden Leerungsmodus beendet. Der Transportanbieter sollte das Herunterladen nicht beenden, aber das Herunterladen sollte im Hintergrund erfolgen. Die status Tabellenzeile für die Transportsitzung sollte durch Aufrufen von ModifyStatusRow aktualisiert werden, wenn der Transportanbieter diese Benachrichtigung erfüllen kann.
NOTIFY_END_OUTBOUND
Ausgehende Vorgänge müssen für diese Transportanbietersitzung beendet werden. Der MAPI-Spooler ruft SubmitMessage nicht mehr auf und ignoriert das SpoolerNotify-NOTIFY_READYTOSEND-Flag . Wenn gerade eine ausgehende Nachricht gesendet wird, sollte sie nicht beendet werden. Um die Zustellung einer Nachricht zu beenden, verwenden Sie das flag NOTIFY_CANCEL_MESSAGE. Die status Tabellenzeile für diese Sitzung sollte aktualisiert werden, indem ModifyStatusRow vor der Rückgabe aufgerufen wird. Die flags NOTIFY_END_INBOUND und NOTIFY_BEGIN_OUTBOUND schließen sich gegenseitig aus.
NOTIFY_END_OUTBOUND_FLUSH
Funktioniert ähnlich wie NOTIFY_END_INBOUND_FLUSH, bezieht sich jedoch auf ausgehende Nachrichten. Das entsprechende status-Flag ist STATUS_OUTBOUND_FLUSH.
lppvData
[out] Ein Zeiger auf einen Zeiger auf ereignisspezifische Daten. Weitere Informationen dazu, was lppvData angibt, finden Sie in der Beschreibung für den lpulFlags-Parameter .
Rückgabewert
S_OK
Der Aufruf war erfolgreich und hat den erwarteten Wert oder die erwarteten Werte zurückgegeben.
Hinweise
Der MAPI-Spooler ruft die IXPLogon::TransportNotify-Methode auf, um den Transportanbieter über Ereignisse zu signalisieren, für die eine Benachrichtigung angefordert wurde. Zu diesen Ereignissen gehören eine MAPI-Spooleranforderung zum Abbrechen einer Nachrichtenübertragung, der Beginn oder das Ende von ein- oder ausgehenden Transportvorgängen sowie der Anfang oder Das Ende eines Vorgangs zum Löschen einer eingehenden oder ausgehenden Nachrichtenwarteschlange.
Wenn der Benutzer versucht, eine Nachricht abzubrechen, die der Transportanbieter zuvor zurückgestellt hat, ruft der MAPI-Spooler TransportNotify auf und übergibt sowohl die NOTIFY_ABORT_DEFERRED- als auch NOTIFY_CANCEL_MESSAGE-Flags in ulFlags. Wenn sich der MAPI-Spooler abmeldet und weiterhin Nachrichten in der Warteschlange enthält, übergibt er beim Aufruf von TransportNotify nur NOTIFY_ABORT_DEFERRED in ulFlags.
Hinweise für Implementierer
Der Anbieter muss den Zugriff auf seine Daten bei diesem Aufruf synchronisieren, da der MAPI-Spooler diese Methode aus einem anderen Ausführungsthread oder aus einer Prozedur für ein anderes Fenster aufrufen kann. Dies tritt höchstwahrscheinlich auf, wenn der MAPI-Spooler den Abbruch einer Nachricht signalisiert, die der Transportanbieter gesendet hat.