IXPLogon::TransportNotify
S’applique à : Outlook 2013 | Outlook 2016
Signale l’occurrence d’un événement au sujet duquel le fournisseur de transport a demandé une notification.
HRESULT TransportNotify(
ULONG FAR * lpulFlags,
LPVOID FAR * lppvData
);
Paramètres
lpulFlags
[in, out] Masque de bits d’indicateurs qui signale des événements de notification. Les indicateurs suivants peuvent être définis par le spouleur MAPI en entrée et doivent être retournés inchangés en sortie :
NOTIFY_ABORT_DEFERRED
Avertit le fournisseur de transport qu’un message dont il a accepté la responsabilité est différé. Seuls les fournisseurs de transport qui prennent en charge le report doivent prendre en charge cet indicateur. Le paramètre lppvData pointe vers l’identificateur d’entrée du message annulé. Les messages que le spouleur MAPI n’a pas traités peuvent toujours être différés en appelant la méthode IMsgStore ::AbortSubmit .
NOTIFY_BEGIN_INBOUND
Le spouleur MAPI peut désormais accepter les messages entrants pour cette session de fournisseur de transport. Le spouleur MAPI appelle régulièrement la méthode IXPLogon ::P oll si le fournisseur de transport définit l’indicateur LOGON_SP_POLL avec l’appel IXPProvider ::TransportLogon lors de l’ouverture de session. Une fois l’indicateur NOTIFY_BEGIN_INBOUND défini, le spouleur MAPI respecte l’indicateur NOTIFY_NEWMAIL passé dans l’appel à la méthode IMAPISupport ::SpoolerNotify . La ligne de table status de la session du fournisseur de transport doit être mise à jour avant d’être retournée en appelant la méthode IMAPISupport ::ModifyStatusRow. Les indicateurs NOTIFY_BEGIN_INBOUND et NOTIFY_END_INBOUND s’excluent mutuellement.
NOTIFY_BEGIN_INBOUND_FLUSH
Indique au fournisseur de transport de parcourir les messages entrants aussi rapidement que possible. Pour se conformer à cette notification, le fournisseur de transport doit définir dès que possible l’indicateur STATUS_INBOUND_FLUSH dans la propriété PR_STATUS_CODE (PidTagStatusCode) de sa ligne de table status, à l’aide de ModifyStatusRow. Un cycle de messagerie entrante est terminé lorsque le fournisseur détermine qu’il a téléchargé tout ce qu’il peut, ou lorsqu’il a reçu un appel de méthode TransportNotify avec l’indicateur NOTIFY_END_INBOUND_FLUSH défini. Jusqu’à la fin du cycle de messagerie entrante, le fournisseur ne doit pas appeler la méthode IMAPISupport ::SpoolerYield ou abandonner les cycles au système d’exploitation pour accélérer la remise des messages entrants. Cela est acceptable, car le spouleur MAPI utilise généralement NOTIFY_BEGIN_INBOUND_FLUSH uniquement en réponse à la demande d’un utilisateur, via une application cliente, pour remettre tous les messages maintenant. À la fin de l’opération de vidage entrant, le fournisseur doit utiliser SpoolerNotify pour effacer l’indicateur STATUS_INBOUND_FLUSH dans la propriété PR_STATUS_CODE de sa ligne status.
NOTIFY_BEGIN_OUTBOUND
Des opérations sortantes peuvent désormais se produire pour cette session de fournisseur de transport. S’il existe des messages à envoyer pour ce fournisseur, un appel à la méthode IXPLogon ::SubmitMessage suit. La ligne de table status pour cette session doit être mise à jour avant de revenir. Les indicateurs NOTIFY_BEGIN_OUTBOUND et NOTIFY_END_OUTBOUND s’excluent mutuellement.
NOTIFY_BEGIN_OUTBOUND_FLUSH
Fonctionne de la même façon que l’indicateur NOTIFY_BEGIN_INBOUND_FLUSH, mais fait référence aux messages sortants. L’indicateur de status approprié est STATUS_OUTBOUND_FLUSH.
NOTIFY_CANCEL_MESSAGE
Le spouleur MAPI doit annuler le transfert du message pour lequel le paramètre lppvData pointe vers la valeur 32 bits de l’appel de méthode IXPLogon ::SubmitMessage . L’indicateur NOTIFY_CANCEL_MESSAGE peut être défini sans que le fournisseur de transport ait renvoyé l’appel de méthode SubmitMessage, IXPLogon ::StartMessage ou IXPLogon ::EndMessage associé au message. Le fournisseur de transport doit retourner dès que possible à partir du point d’entrée qui gère le message annulé. Pour un message entrant en cours de traitement, le fournisseur de transport doit enregistrer le message entrant partout où il est actuellement stocké et le remettre à l’heure suivante. Les données de l’objet message déjà stockées pour le message entrant sont ignorées. Si le fournisseur de transport n’a pas mis à jour cette valeur 32 bits à l’heure StartMessage ou SubmitMessage , la valeur est 0 pour les messages sortants et 1 pour les messages entrants.
NOTIFY_END_INBOUND
Les opérations entrantes doivent cesser pour cette session de fournisseur de transport. Le spouleur MAPI cesse d’utiliser la méthode Poll et ignore NOTIFY_NEWMAIL pour cette session. Les messages in-process doivent être renseignés. La ligne de table status pour la session de transport doit être mise à jour en appelant ModifyStatusRow avant de retourner. Les indicateurs NOTIFY_END_INBOUND et NOTIFY_BEGIN_INBOUND s’excluent mutuellement.
NOTIFY_END_INBOUND_FLUSH
Avertit le fournisseur de transport de sortir du mode de vidage entrant. Le fournisseur de transport ne doit pas arrêter le téléchargement, mais le téléchargement doit être effectué en arrière-plan. La ligne de table status pour la session de transport doit être mise à jour en appelant ModifyStatusRow lorsque le fournisseur de transport peut se conformer à cette notification.
NOTIFY_END_OUTBOUND
Les opérations sortantes doivent cesser pour cette session de fournisseur de transport. Le spouleur MAPI cesse d’appeler SubmitMessage et ignore l’indicateur SpoolerNotify NOTIFY_READYTOSEND. Si un message sortant est actuellement envoyé, il ne doit pas être arrêté ; pour arrêter la remise d’un message, utilisez l’indicateur NOTIFY_CANCEL_MESSAGE. La ligne de table status pour cette session doit être mise à jour en appelant ModifyStatusRow avant de retourner. Les indicateurs NOTIFY_END_INBOUND et NOTIFY_BEGIN_OUTBOUND s’excluent mutuellement.
NOTIFY_END_OUTBOUND_FLUSH
Fonctionne de la même façon que NOTIFY_END_INBOUND_FLUSH, mais fait référence aux messages sortants. L’indicateur de status approprié est STATUS_OUTBOUND_FLUSH.
lppvData
[out] Pointeur vers un pointeur vers des données spécifiques à l’événement. Pour plus d’informations sur ce que lppvData spécifie, consultez la description du paramètre lpulFlags .
Valeur renvoyée
S_OK
L’appel a réussi et a retourné la ou les valeurs attendues.
Remarques
Le spouleur MAPI appelle la méthode IXPLogon ::TransportNotify pour signaler au fournisseur de transport les événements pour lesquels une notification a été demandée. Ces événements incluent une demande de spouleur MAPI pour annuler un transfert de messages, le début ou la fin des opérations de transport entrant ou sortant, et le début ou la fin d’une opération pour effacer une file d’attente de messages entrants ou sortants.
Lorsque l’utilisateur tente d’annuler un message que le fournisseur de transport a précédemment différé, le spouleur MAPI appelle TransportNotify, en transmettant les indicateurs NOTIFY_ABORT_DEFERRED et NOTIFY_CANCEL_MESSAGE dans ulFlags. Si le spouleur MAPI se déconnecte et a toujours des messages dans la file d’attente, il passe uniquement NOTIFY_ABORT_DEFERRED dans ulFlags lorsqu’il appelle TransportNotify.
Remarques pour les responsables de l’implémentation
Le fournisseur doit synchroniser l’accès à ses données sur cet appel, car le spouleur MAPI peut appeler cette méthode à partir d’un autre thread d’exécution ou d’une procédure pour une autre fenêtre. Cela se produit probablement lorsque le spouleur MAPI signale l’annulation d’un message que le fournisseur de transport a commencé à envoyer.