Anrufsynchronisierung

COM-Anwendungen müssen in der Lage sein, benutzereingaben bei der Verarbeitung eines oder mehrerer Aufrufe von COM oder dem Betriebssystem ordnungsgemäß zu behandeln. COM stellt die Anrufsynchronisierung nur für Singlethread-Apartments bereit. Multithread-Apartments (mit Freithreadthreadthread-Threads) empfangen keine Anrufe beim Tätigen von Anrufen (im selben Thread). Multithread-Apartments können keine eingabesynchronen Anrufe tätigen. Asynchrone Aufrufe werden in synchrone Aufrufe in Multithread-Apartments konvertiert. Der Nachrichtenfilter wird für keinen Thread in einem Multithread-Apartment aufgerufen. Weitere Informationen zu Threadingproblemen finden Sie unter Prozesse, Threads und Apartments.

COM-Aufrufe zwischen Prozessen werden wie folgt in drei Kategorien unterteilt:

Synchrone Aufrufe

Die meiste Kommunikation, die innerhalb von COM stattfindet, ist synchron. Bei synchronen Anrufen wartet der Anrufer auf die Antwort, bevor er fortfährt, und kann während des Wartens eingehende Nachrichten empfangen. COM tritt in eine modale Schleife ein, um auf die Antwort zu warten und andere Nachrichten kontrolliert zu empfangen und zu versenden.

Asynchrone Benachrichtigungen

Beim Senden asynchroner Benachrichtigungen wartet der Aufrufer nicht auf die Antwort. COM verwendet PostMessage oder allgemeine Ereignisse, um asynchrone Benachrichtigungen zu senden, je nach Plattform. COM definiert fünf asynchrone Methoden von IAdviseSink:

• OnDataChange
• OnViewChange
• OnRename
• Onsave
• OnClose

Hinweis

Während COM einen asynchronen Aufruf verarbeitet, können keine synchronen Aufrufe ausgeführt werden. Die Implementierung von OnDataChange einer Containeranwendung kann beispielsweise keinen Aufruf von IPersistStorage::Save enthalten. Diese Aufrufe sind die einzigen asynchronen Aufrufe, die von COM unterstützt werden. Es gibt keine Möglichkeit, eine benutzerdefinierte Schnittstelle zu erstellen, die derzeit asynchron ist.

 

Eingabesynchrone Aufrufe

Beim Ausführen von eingabesynchronen Aufrufen muss das aufgerufene Objekt den Aufruf abschließen, bevor das Steuerelement zurückgegeben wird. Dadurch wird sichergestellt, dass die Fokusverwaltung ordnungsgemäß funktioniert und vom Benutzer eingegebene Daten entsprechend verarbeitet werden. Diese Aufrufe werden von COM über die SendMessage-Funktion ausgeführt, ohne in eine modale Schleife zu gelangen. Bei der Verarbeitung eines eingabesynchronen Aufrufs darf das aufgerufene Objekt keine Funktion oder Methode (einschließlich synchroner Methoden) aufrufen, die eine Steuerung ergeben könnten. Die folgenden Methoden werden eingabesynchronisiert

• IOleWindow::GetWindow
• IOleInPlaceActiveObject::OnFrameWindowActivate
• IOleInPlaceActiveObject::OnDocWindowActivate
• IOleInPlaceActiveObject::ResizeBorder
• IOleInPlaceUIWindow::GetBorder
• IOleInPlaceUIWindow::RequestBorderSpace
• IOleInPlaceUIWindow::SetBorderSpace
• IOleInPlaceFrame::SetMenu
• IOleInPlaceFrame::SetStatusText
• IOleInPlaceObject::SetObjectRects

Um Probleme zu minimieren, die bei der asynchronen Nachrichtenverarbeitung auftreten können, sind die meisten COM-Methodenaufrufe synchron. Bei synchroner Kommunikation ist kein spezieller Code erforderlich, um eingehende Nachrichten zu senden und zu verarbeiten. Wenn eine Anwendung einen synchronen Methodenaufruf ausgibt, tritt COM in eine modale Warteschleife ein, die die erforderlichen Antworten verarbeitet und eingehende Nachrichten an Anwendungen sendet, die diese verarbeiten können.

COM verwaltet Methodenaufrufe durch Zuweisen eines Bezeichners namens einer logischen Thread-ID. Eine neue wird zugewiesen, wenn ein Benutzer einen Menübefehl auswählt oder wenn die Anwendung einen neuen COM-Vorgang initiiert. Nachfolgenden Aufrufen, die sich auf den anfänglichen COM-Aufruf beziehen, wird dieselbe logische Thread-ID zugewiesen wie der erste Aufruf.