Méthode IMessageFilter ::MessagePending (objidl.h)

Indique qu’un message est arrivé alors que COM attend de répondre à un appel distant.

La gestion des entrées en attendant la fin d’un appel sortant peut entraîner des complications. L’application doit déterminer s’il faut traiter le message sans interrompre l’appel, continuer à attendre ou annuler l’opération.

Syntaxe

DWORD MessagePending(
  [in] HTASK htaskCallee,
  [in] DWORD dwTickCount,
  [in] DWORD dwPendingType
);

Paramètres

[in] htaskCallee

ID de thread de l’application appelée.

[in] dwTickCount

Nombre de cycles depuis l’appel. Elle est calculée à partir de la fonction GetTickCount .

[in] dwPendingType

Type d’appel effectué au cours duquel un message ou un événement a été reçu. Les valeurs possibles proviennent de l’énumération PENDINGTYPE, où PENDINGTYPE_TOPLEVEL signifie que l’appel sortant n’a pas été imbriqué dans un appel d’une autre application et PENDINTGYPE_NESTED signifie que l’appel sortant a été imbriqué dans un appel d’une autre application.

Valeur retournée

Cette méthode peut retourner les valeurs suivantes.

Remarques

COM appelle MessagePending après qu’une application a effectué un appel de méthode COM et qu’un message Windows se produit avant le retour de l’appel. Un message Windows est envoyé, par exemple, lorsque l’utilisateur sélectionne une commande de menu ou double-clique sur un objet. Avant que COM effectue l’appel MessagePending , il calcule le temps écoulé depuis l’appel de la méthode COM d’origine. COM fournit le temps écoulé dans le paramètre dwTickCount . En attendant, COM ne supprime pas le message de la file d’attente.

Les messages Windows qui s’affichent dans la file d’attente de l’appelant doivent rester dans la file d’attente jusqu’à ce que suffisamment de temps soit écoulé pour s’assurer que les messages ne sont probablement pas le résultat de la saisie à l’avance, mais qu’ils sont plutôt une tentative d’attirer l’attention. Définissez le délai avec le paramètre dwTickCount : un délai de deux ou trois secondes est recommandé. Si ce laps de temps s’écoule et que l’appel n’est pas terminé, l’appelant doit vider les messages de la file d’attente et la boîte de dialogue ole ui busy doit s’afficher, offrant à l’utilisateur le choix de réessayer l’appel (continuer à attendre) ou de basculer vers la tâche spécifiée. Cela garantit les comportements suivants :

• Si les appels sont terminés dans un laps de temps raisonnable, le type à l’avance est traité correctement.
• Si l’appelé ne répond pas, le type avant n’est pas mal interprété et l’utilisateur peut agir pour résoudre le problème. Par exemple, les serveurs OLE 1 peuvent mettre en file d’attente les requêtes sans répondre lorsqu’elles se trouvent dans des boîtes de dialogue modales.

En l’absence de réponse à l’appel COM d’origine, l’application peut annuler l’appel et restaurer l’objet COM à un état cohérent en appelant IStorage ::Revert sur son stockage. L’objet peut être libéré lorsque le conteneur peut s’arrêter. Toutefois, l’annulation d’un appel peut créer des opérations orphelines et des fuites de ressources. L’annulation ne doit être utilisée qu’en dernier recours. Il est vivement recommandé que les applications n’autorisent pas l’annulation de tels appels.

Configuration requise

Voir aussi

IMessageFilter

OleUIBusy