IMessageFilter::MessagePending-Methode (objidl.h)

Artikel
03/06/2024

Gibt an, dass eine Nachricht eingegangen ist, während COM darauf wartet, auf einen Remoteanruf zu antworten.

Die Verarbeitung von Eingaben während des Wartens auf den Abschluss eines ausgehenden Anrufs kann zu Komplikationen führen. Die Anwendung sollte bestimmen, ob die Nachricht verarbeitet werden soll, ohne den Aufruf zu unterbrechen, weiter zu warten oder den Vorgang abzubrechen.

Syntax

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

Parameter

[in] htaskCallee

Die Thread-ID der aufgerufenen Anwendung.

[in] dwTickCount

Die Anzahl der Ticks seit dem Anruf. Sie wird aus der GetTickCount-Funktion berechnet.

[in] dwPendingType

Der Typ des Anrufs, bei dem eine Nachricht oder ein Ereignis empfangen wurde. Mögliche Werte stammen aus der Enumeration PENDINGTYPE, wobei PENDINGTYPE_TOPLEVEL bedeutet, dass der ausgehende Aufruf nicht in einem Aufruf einer anderen Anwendung geschachtelt wurde und PENDINTGYPE_NESTED bedeutet, dass der ausgehende Aufruf in einem Aufruf einer anderen Anwendung geschachtelt wurde.

Rückgabewert

Diese Methode kann die folgenden Werte zurückgeben.

Rückgabecode	Beschreibung
PENDINGMSG_CANCELCALL	Abbrechen des ausgehenden Anrufs. Diese sollte nur unter extremen Bedingungen zurückgegeben werden. Das Abbrechen eines Aufrufs, der nicht geantwortet oder abgelehnt wurde, kann verwaiste Transaktionen erstellen und Ressourcen verlieren. COM schlägt den ursprünglichen Aufruf fehl und gibt RPC_E_CALL_CANCELLED zurück.
PENDINGMSG_WAITNOPROCESS	Nicht verwendet.
PENDINGMSG_WAITDEFPROCESS	Tastatur- und Mausnachrichten werden nicht mehr gesendet. Es gibt jedoch einige Fälle, in denen Maus- und Tastaturmeldungen das System zu einem Deadlock führen können, und in diesen Fällen werden Maus- und Tastaturmeldungen verworfen. WM_PAINT Nachrichten werden gesendet. Aufgabenwechsel- und Aktivierungsmeldungen werden wie zuvor behandelt.

Hinweise

COM ruft MessagePending auf, nachdem eine Anwendung einen COM-Methodenaufruf ausgeführt hat und eine Windows-Nachricht auftritt, bevor der Aufruf zurückgegeben wurde. Eine Windows-Nachricht wird beispielsweise gesendet, wenn der Benutzer einen Menübefehl auswählt oder auf ein Objekt doppelt klickt. Bevor COM den MessagePending-Aufruf ausgibt, berechnet es die verstrichene Zeit seit dem ursprünglichen AUFRUF der COM-Methode. COM liefert die verstrichene Zeit im dwTickCount-Parameter . In der Zwischenzeit entfernt COM die Nachricht nicht aus der Warteschlange.

Windows-Nachrichten, die in der Warteschlange des Aufrufers angezeigt werden, sollten in der Warteschlange bleiben, bis genügend Zeit verstrichen ist, um sicherzustellen, dass die Nachrichten wahrscheinlich nicht das Ergebnis einer Vorauseingabe sind, sondern stattdessen ein Versuch sind, Aufmerksamkeit zu erhalten. Legen Sie die Verzögerung mit dem dwTickCount-Parameter fest – eine Verzögerung von zwei Sekunden oder drei Sekunden wird empfohlen. Wenn diese Zeit verstreicht und der Anruf nicht abgeschlossen wurde, sollte der Aufrufer die Nachrichten aus der Warteschlange löschen, und das Dialogfeld OLE UI busy sollte angezeigt werden, um dem Benutzer die Wahl zu geben, den Anruf erneut zu versuchen (warten sie weiter) oder zur angegebenen Aufgabe zu wechseln. Dadurch werden die folgenden Verhaltensweisen sichergestellt:

Wenn Aufrufe in einem angemessenen Zeitraum abgeschlossen werden, wird der Typ voraus ordnungsgemäß behandelt.
Wenn der Angerufene nicht antwortet, wird die Eingabe voraus nicht falsch interpretiert, und der Benutzer kann handeln, um das Problem zu lösen. Beispielsweise können OLE 1-Server Anforderungen in die Warteschlange stellen, ohne zu reagieren, wenn sie sich in modalen Dialogfeldern befinden.

Wenn keine Antwort auf den ursprünglichen COM-Aufruf vorhanden ist, kann die Anwendung den Aufruf abbrechen und das COM-Objekt in einen konsistenten Zustand wiederherstellen, indem IStorage::Revert im Speicher aufgerufen wird. Das Objekt kann freigegeben werden, wenn der Container heruntergefahren werden kann. Das Abbrechen eines Anrufs kann jedoch zu verwaisten Vorgängen und Ressourcenverlusten führen. Das Abbrechen sollte nur als letztes Mittel verwendet werden. Es wird dringend empfohlen, dass Anwendungen das Abbrechen solcher Aufrufe nicht zulassen.

Hinweis Obwohl der htaskCallee-Parameter als HTASK eingegeben wird, enthält er die Thread-ID des aufgerufenen Threads. Wenn Sie die IMessageFilter-Schnittstelle implementieren, können Sie die OpenThread-Funktion aufrufen, um das Threadhandle aus dem htaskCallee-Parameter abzurufen, und Sie können die GetProcessIdOfThread-Funktion aufrufen, um die Prozess-ID abzurufen.

Anforderungen

Anforderung	Wert
Unterstützte Mindestversion (Client)	Windows 2000 Professional [nur Desktop-Apps]
Unterstützte Mindestversion (Server)	Windows 2000 Server [nur Desktop-Apps]
Zielplattform	Windows
Kopfzeile	objidl.h

Weitere Informationen

Imessagefilter

OleUIBusy

Share via