IMessageFilter-Schnittstelle (objidl.h)

Bietet COM-Servern und -Anwendungen die Möglichkeit, ein- und ausgehende COM-Nachrichten selektiv zu verarbeiten, während sie auf Antworten von synchronen Aufrufen warten. Durch das Filtern von Nachrichten wird sichergestellt, dass Anrufe so behandelt werden, dass die Leistung verbessert und Deadlocks vermieden werden. COM-Nachrichten können synchron, asynchron oder eingabesynchron sein. die meisten Schnittstellenaufrufe sind synchron.

Vererbung

Die IMessageFilter-Schnittstelle erbt von der IUnknown-Schnittstelle . IMessageFilter verfügt auch über folgende Membertypen:

Methoden

Die IMessageFilter-Schnittstelle verfügt über diese Methoden.

IMessageFilter::HandleInComingCall Stellt einen einzelnen Einstiegspunkt für eingehende Anrufe bereit.
IMessageFilter::MessagePending Gibt an, dass eine Nachricht eingegangen ist, während COM darauf wartet, auf einen Remoteanruf zu antworten.
IMessageFilter::RetryRejectedCall Bietet Anwendungen die Möglichkeit, ein Dialogfeld mit Wiederholungs-, Abbruch- oder Aufgabenwechseloptionen anzuzeigen.

Hinweise

Synchrone Aufrufe erfordern, dass der Aufrufer auf eine Antwort wartet, bevor er fortfährt. COM tritt beim Warten auf die Antwort in eine modale Schleife ein. Während dieser Zeit ist der Anrufer weiterhin in der Lage, eingehende Nachrichten zu empfangen und zu senden.

Asynchrone Aufrufe ermöglichen es dem Aufrufer, fortzufahren, ohne auf eine Antwort des aufgerufenen Objekts zu warten. Heute sind in COM die einzigen asynchronen Aufrufe an die IAdviseSink-Schnittstelle eines Objekts. Während das -Objekt einen asynchronen Aufruf verarbeitet, ist es untersagt, synchrone Aufrufe an das aufrufende Objekt zurück zu tätigen.

Damit Verhaltensweisen wie Fokusverwaltung und Type-Ahead ordnungsgemäß funktionieren, müssen eingabesynchrone Aufrufe das aufgerufene Objekt den Aufruf abschließen, bevor das Steuerelement aufgegeben wird.

Herunterfahren der Anwendung mit WM_QUERYENDSESSION und WM_ENDSESSION

Wenn ein Benutzer Windows beendet, erhält jede geöffnete Anwendung eine WM_QUERYENDSESSION-Nachricht gefolgt von einer WM_ENDSESSION-Nachricht , sofern der Exit nicht abgebrochen wird. Diese Nachrichten werden mit der SendMessage-Funktion aufgerufen, die leider die Initiierung aller ausgehenden LRPC-Aufrufe einschränkt. Dies ist ein Problem für Containeranwendungen, die über offene eingebettete Objekte verfügen, wenn sie die Herunterfahrensanforderung empfangen, da LRPC zum Schließen dieser Objekte erforderlich ist.

Container- und Container-/Serveranwendungen mit geöffneten Dokumenten zeigen in der Regel beim Empfang der WM_QUERYENDSESSION Nachricht ein Meldungsfeld an, in dem gefragt wird, ob der Benutzer Änderungen vor dem Beenden speichern möchte. Eine positive Antwort ist normalerweise die Standardeinstellung. Die Empfehlung für den Umgang mit der oben beschriebenen Situation besteht darin, dass die Anwendung ein alternatives Meldungsfeld anzeigt, in dem gefragt wird, ob der Benutzer Änderungen verwerfen möchte. Eine negative Antwort sollte die Standardeinstellung sein. Wenn der Benutzer die Änderungen verwirft, sollte true für WM_QUERYENDSESSION zurückgegeben werden, was Windows signalisiert, dass es beendet werden kann. Wenn der Benutzer die Änderungen nicht verwerfen möchte, sollte FALSE zurückgegeben werden. Es sollte kein Versuch unternommen werden, ausgeführte Einbettungen zu schließen oder freizugeben.

Serveranwendungen sollten true für WM_QUERYENDSESSION zurückgeben, ohne dass der Benutzer dazu aufgefordert wird. Nach Erhalt einer WM_ENDSESSION Nachricht sollten alle COM-Anwendungen die normale Close-Sequenz für die Dokumente und Objekte jeder Anwendung ausführen. Gleichzeitig sollten Sie alle Fehler ignorieren, die sich aus prozessübergreifenden Aufrufen oder Aufrufen von IUnknown::Release ergeben. Alle Speicherzeiger (IStorage - und IStream-Schnittstellenzeiger ) müssen freigegeben werden, um alle temporären Dateien ordnungsgemäß zu löschen, die von der Verbunddateiimplementierung des strukturierten Speichers verwaltet werden.

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