Eine Containeranwendung muss in der Lage sein, eine Präsentation eines Objekts abzurufen, um es benutzern anzuzeigen oder auszudrucken, wenn das Dokument geöffnet ist, die Serveranwendung des Objekts jedoch nicht ausgeführt wird oder nicht auf dem Computer des Benutzers installiert ist. Davon auszugehen, dass die Server für alle Objekte, die sich in einem Dokument befinden könnten, auf dem Computer jedes Benutzers installiert sind und immer bei Bedarf ausgeführt werden können, ist unrealistisch. Der Standardobjekthandler, der jederzeit verfügbar ist, löst dieses Dilemma, indem er Objektpräsentationen im Dokumentspeicher zwischenspeichert und diese Präsentationen auf einer beliebigen Plattform bearbeitet, unabhängig von der Verfügbarkeit des Objektservers bei einer bestimmten Installation des Containers.
Container können Zeichnungspräsentationen für ein oder mehrere bestimmte Zielgeräte verwalten, zusätzlich zu dem, der zum Verwalten des Objekts auf dem Bildschirm erforderlich ist. Wenn Sie das Objekt außerdem von einer Plattform auf eine andere portieren, konvertiert OLE automatisch die Datenformate des Objekts in die auf der neuen Plattform unterstützten Formate. Wenn Sie beispielsweise ein Objekt von Windows auf den Macintosh verschieben, konvertiert OLE seine Metadateipräsentationen in PICT-Formate.
Um dem Benutzer eine genaue Darstellung eines eingebetteten Objekts zu präsentieren, initiiert die Containeranwendung des Objekts einen Dialog mit dem Objekthandler und fordert Daten und Zeichnungsanweisungen an. Um die Anforderungen des Containers erfüllen zu können, muss der Handler die Schnittstellen IDataObject, IViewObject2 und IOleCache implementieren.
IDataObject ermöglicht es einer OLE-Containeranwendung, Daten von ihren eingebetteten oder verknüpften Objekten abzurufen und Daten zu senden. Wenn Sich Daten in einem Objekt ändern, bietet diese Schnittstelle eine Möglichkeit für das Objekt, seine neuen Daten für seinen Container verfügbar zu machen, und bietet dem Container eine Möglichkeit, die Daten in seiner Kopie des Objekts zu aktualisieren. (Eine Allgemeine Erläuterung der Datenübertragung finden Sie in Kapitel 4, Datenübertragung.)
Die IViewObject2-Schnittstelle ähnelt der IDataObject-Schnittstelle sehr, mit dem Unterschied, dass ein Objekt aufgefordert wird, sich selbst in einem Gerätekontext zu zeichnen, z. B. auf einem Bildschirm, drucker oder einer Metadatei, anstatt seine Daten in den Arbeitsspeicher oder ein anderes Übertragungsmedium zu verschieben oder zu kopieren. Der Zweck der Schnittstelle besteht darin, einem OLE-Container das Abrufen alternativer bildlicher Darstellungen seiner eingebetteten Objekte zu ermöglichen, deren Daten bereits vorhanden sind, wodurch der Mehraufwand vermieden wird, völlig neue Instanzen derselben Datenobjekte zu übertragen, um einfach neue Zeichnungsanweisungen zu erhalten. Stattdessen ermöglicht die IViewObject2-Schnittstelledem Container, ein Objekt aufzufordern, eine bildliche Darstellung seiner selbst bereitzustellen, indem es auf einem vom Container angegebenen Gerätekontext zeichnet.
Beim Aufrufen der IViewObject2-Schnittstelle kann eine Containeranwendung auch angeben, dass das Objekt sich selbst auf einem Anderen Zielgerät zeichnet als auf dem, auf dem es tatsächlich gerendert wird. Dadurch kann der Container bei Bedarf unterschiedliche Renderings aus einem einzelnen Objekt generieren. Beispielsweise könnte der Aufrufer das Objekt bitten, sich selbst für einen Drucker zu verfassen, obwohl die resultierende Zeichnung auf dem Bildschirm gerendert wird. Das Ergebnis wäre natürlich eine Druckvorschau des Objekts.
Die IViewObject2-Schnittstellebietet auch Methoden, mit denen Container sich für Ansichtsänderungsbenachrichtigungen registrieren können. Wie bei Daten- und OLE-Empfehlungen ermöglicht eine Ansichtsempfehlungsverbindung einem Container, seine Renderings eines Objekts nach eigener Belieben zu aktualisieren, anstatt auf einen Aufruf des Objekts zu reagieren. Wenn beispielsweise eine neue Version der Serveranwendung eines Objekts zusätzliche Ansichten derselben Daten bieten würde, ruft der Standardhandler des Objekts die Implementierung von IAdviseSink::OnViewChange für jeden Container auf, um sie darüber zu informieren, dass die neuen Präsentationen verfügbar waren. Der Container ruft diese Informationen nur bei Bedarf aus der Empfehlungssenke ab.
Da Windows-Gerätekontexte nur innerhalb eines einzelnen Prozesses Bedeutung haben, können Sie IViewObject2-Zeiger nicht über Prozessgrenzen hinweg übergeben. Daher müssen lokale OLE- und Remoteserver die Schnittstelle nicht implementieren, was selbst dann nicht ordnungsgemäß funktionieren würde. Nur Objekthandler und prozessinterne Server implementieren die IViewObject2-Schnittstelle. OLE stellt eine Standardimplementierung bereit, die Sie in Ihren eigenen OLE-Prozessservern und Objekthandlern verwenden können, indem Sie einfach den OLE-Standardhandler aggregieren. Oder Sie können Ihre eigene Implementierung von IViewObject2 schreiben.
Ein -Objekt implementiert die IOleCache-Schnittstelle , um dem Handler mitzuteilen, welche Funktionen zwischengespeichert werden sollen. Der Objekthandler besitzt auch den Cache und stellt sicher, dass er auf dem neuesten Stand bleibt. Wenn das eingebettete Objekt in den Ausführungszustand wechselt, richtet der Handler geeignete Beratungsverbindungen für das Serverobjekt ein, wobei sich selbst als Senke fungiert. Die Implementierungen der IDataObject - und IViewObject2-Schnittstellewerden aus Daten ausgeführt, die auf der Clientseite zwischengespeichert werden. Die Implementierung von IViewObject2des Handlers bestimmt, welche Datenformate zwischengespeichert werden sollen, um Clientzeichnungsanforderungen zu erfüllen. Die Implementierung von IDataObject des Handlers ist für das Abrufen von Daten in verschiedenen Formaten usw. zwischen Arbeitsspeicher und dem zugrunde liegenden IStorage-instance des eingebetteten Objekts verantwortlich. Benutzerdefinierte Handler können diese Implementierungen verwenden, indem sie im Standardhandler aggregieren.
Hinweis
Die IViewObject2-Schnittstelle ist eine einfache Funktionserweiterung von IViewObject und sollte anstelle der letzten Schnittstelle implementiert werden, die jetzt veraltet ist. Zusätzlich zur Bereitstellung der IViewObject-Methoden bietet die IViewObject2-Schnittstelle ein einzelnes zusätzliches Element, GetExtent, mit dem eine Containeranwendung die Größe der Präsentation eines Objekts aus dem Cache abrufen kann, ohne das Objekt zuerst mit einem Aufruf von IOleObject::GetExtent in den ausführungszustand verschieben zu müssen.
Erfahren Sie mehr über die mit Microsoft Graph-Toolkit angebotenen Caching-Funktionen und entdecken Sie, wie Sie schnell mehr Daten anzeigen können, die Sie möglicherweise in Microsoft Graph-Toolkit-Komponenten benötigen.