DE69327138T2

DE69327138T2 - Verfahren zur Namensgebung und zur Bindung von Objekten

Info

Publication number: DE69327138T2
Application number: DE69327138T
Authority: DE
Inventors: Robert G. Atkinson; Edward K. Jung; Antony S. Williams
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1992-07-06
Filing date: 1993-07-06
Publication date: 2000-04-27
Anticipated expiration: 2013-07-07
Also published as: US20070061817A1; EP0930566A3; US7441253B2; DE69327138D1; US5842018A; US5689703A; JPH06195339A; KR940006027A; JP3613401B2; EP0930566A2; US5682536A; CA2099918A1; US6263379B1; US20070061816A1; US5581760A; US5740439A; KR100287045B1; US20030200504A1; ATE187268T1; EP0578207A2

Description

Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich allgemein auf ein Verfahren und ein System zur Namensgebung und zur Bindung von Objekten und speziell auf ein verallgemeinertes Verfahren zur Namensgebung verbundener Objekte, die in anderen Objekten enthalten sein können, dem Auffinden und Verbinden der Quellen verbundener Objekte und dem Reduzieren der Anzahl von Serveraufrufen, die zum Binden eines Objektes benötigt werden.

Beschreibung des Standes der Technik

Gängige Computersysteme zur Dokumentenverarbeitung erlauben einem Benutzer, zusammengesetzte Dokumente vorzubereiten. Ein zusammengesetztes Dokument ist ein Dokument, welches Information in verschiedenen Formaten enthält. Z. B. kann ein zusammengesetztes Dokument Daten in Textformat, tabellarischem Format, numerischem Format etc. enthalten. Fig. 1 ist ein Beispiel eines zusammengesetzten Dokuments. In diesem Beispiel wird das zusammengesetzte Dokument 101 als Bericht für ein bestimmtes Fertigungsprojekt generiert. Das zusammengesetzte Dokument 101 enthält Planungsdaten 102, die in tabellarischem Format dargestellt sind; Budgetdaten 103, die in Tabellenkalkulationsformat (spread sheet format) dargestellt sind; und erklärende Daten 104, die in Textformat dargestellt sind. In typischen früheren Systemen generiert ein Benutzer die Planungsdaten 102 mit einem Projektverwaltungscomputerprogramm (project management computer program) und die Budgetdaten 103 mit einem Tabellenkalkulationscomputerprogramm. Nachdem diese Daten generiert wurden, erzeugt der Benutzer das zusammengesetzte Dokument 101, gibt die erklärenden Daten 104 ein und verbindet die Planungsdaten 102 und Budgetdaten 103 mit einem Textverarbeitungscomputerprogramm.
Fig. 2 zeigt, wie die Planungsdaten, Budgetdaten und erklärenden Daten in ein zusammengesetztes Dokument aufgenommen werden können. Der Benutzer generiert Planungsdaten mit dem Projektverwaltungsprogramm 201 und speichert dann die Daten in der Zwischenablage (clipboard) 203. Der Benutzer generiert Budgetdaten mit dem Tabellenkalkulationsprogramm 204 und speichert dann die Daten in der Zwischenablage 203. Die Zwischenablage 203 ist ein Speicherbereich (Diskette oder Speicher), auf den typischerweise irgendein Programm zugreifen kann. Das Projektverwaltungsprogramm 201 und das Tabellenkalkulationsprogramm 204 speichern typischerweise die Daten in der Zwischenablage in einem Präsentationsformat. Ein Präsentationsformat ist ein Format, in welchem die Daten in einfacher Weise auf einer Ausgabevorrichtung dargestellt werden kann. Z. B. das Präsentationsformat kann ein Pixelmuster (bit map) sein, welches mit einem Standard Pixelmusterblockübertragungsvorgang (BitBlt) dargestellt werden kann. Das Speichern von Daten in einer Zwischenablage wird als "Kopieren" in die Zwischenablage bezeichnet.
Nachdem Daten in die Zwischenablage 203 kopiert wurden, startet der Benutzer das Textverarbeitungsprogramm 206, um das zusammengesetzte Dokument 101 zu erzeugen. Der Benutzer gibt die erklärenden Daten 104 ein und spezifiziert die Stellen in dem zusammengesetzten Dokument 101, an die die Planungsdaten und Budgetdaten, die in der Zwischenablage 203 sind, kopiert werden sollen. Das Kopieren der Daten in der Zwischenablage in ein Dokument wird als "Einfügen" von der Zwischenablage bezeichnet. Das Textverarbeitungsprogramm 206 kopiert dann die Planungsdaten 102 und die Budgetdaten von der Zwischenablage 203 in das zusammengesetzte Dokument 101 an die spezifizierte Stelle. Daten, die von der Zwischenablage in das zusammengesetzte Dokument kopiert werden, werden als "eingebettete" Daten bezeichnet. Das Textverarbeitungsprogramm 206 behandelt die eingebetteten Daten als einfache Pixelmuster, die es mit einem BitBlt-Vorgang darstellt, wenn das zusammengesetzte Dokument 101 auf einer Ausgabevorrichtung wiedergegeben werden soll. In einigen früheren Systemen konnte die Zwischenablage nur in der Lage sein, Daten für einen Kopierbefehl auf einmal zu speichern. In solchen Systemen können die Planungsdaten in die Zwischenablage kopiert werden und dann in das zusammengesetzte Dokument eingefügt werden. Dann können die Budgetdaten in die Zwischenablage kopiert werden und dann in das zusammengesetzte Dokument eingefügt werden.
Da Textverarbeitungsprogramme typischerweise nur Textdaten verarbeiten, können Benutzer von Textverarbeitungsprogrammen eingebettete Daten verschieben oder löschen, können eingebettete Daten aber nicht modifizieren, außer wenn die Daten in Textformat sind. Deshalb, wenn ein Benutzer z. B. die Budgetdaten 103, die in dem zusammengesetzten Dokument 101 sind, modifizieren will, muß der Benutzer das Tabellenkalkulationsprogramm 204 starten, die Budgetdaten 103 von einer Datei laden, die Modifizierungen ausführen, die Modifizierungen in die Zwischenablage 203 kopieren, das Textverarbeitungsprogramm 206 starten, das zusammengesetzte Dokument 101 laden und die modifizierten Daten aus der Zwischenablage in das zusammengesetzte Dokument 101 einfügen.
Einige frühere Systeme speichern Verweise (links) auf die Daten, die in das zusammengesetzte Dokument eingebunden werden sollen, eher als das eigentliche Einbetten der Daten. Wenn ein Textverarbeitungsprogramm die Daten von der Zwischenablage in ein zusammengesetztes Dokument einfügt, wird ein Verweis in dem zusammengesetzten Dokument gespeichert. Der Verweis zeigt auf die Daten (typischerweise in einer Datei gespeichert), die eingefügt werden sollen. Diese früheren Systeme stellen typischerweise Verweise auf Daten in einem Format zur Verfügung, welches das Textverarbeitungsprogramm erkennt oder im Präsentationsfomrat behandelt. Z. B. wenn das Textverarbeitungsprogramm 206 von einem Benutzer angewiesen wird, die Planungsdaten und Budgetdaten in das zusammengesetzte Dokument mit Verweisen einzufügen, eher als durch Einbetten, werden die Namen der Dateien, in denen die Planungsdaten und Budgetdaten im Präsentationsformat gespeichert sind, in das Dokument eingefügt. Mehrere zusammengesetzte Dokumente können Verweise auf die gleichen Daten enthalten, um zu erlauben, daß eine Kopie der Daten von mehreren zusammengesetzten Dokumenten geteilt wird.

Zusammenfassung der Erfindung

Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren nach den angehängten Ansprüchen zum Generieren von Verweisen auf Daten, die in ein zusammengesetztes Dokument eingebunden sind, anzugeben.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, Verweise an die darunterliegenden Daten zu binden.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, diese Verweise auf eine Art zu bearbeiten, die unabhängig von den darunter liegenden Daten ist.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, Daten zu verbinden, die auf einer beliebigen Ebene innerhalb des zusammengesetzten Dokuments verschachtelt sind.
Diese und weitere Aufgaben, die durch die ausführlichere Beschreibung der Erfindung offensichtlicher werden, werden durch ein Verfahren zur Namensgebung und zum Binden von Datenobjekten gelöst. In einer bevorzugten Ausführungsform wird ein Verweis auf ein anderes eingebundenes Objekt als ein Verweisobjekt (Moniker) gespeichert. Ein Verweisobjekt ist ein Objekt, welches die Information verkapselt, die zum Zugriff auf die eingebetteten Daten benötigt wird, und Verfahren zur Verfügung stellt, welche an die eingebetteten Daten binden.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Beispiel eines zusammengesetzten Dokuments.
Fig. 2 zeigt wie die Planungsdaten, Budgetdaten und erklärenden Daten in das zusammengesetzte Dokument eingebettet werden können.
Fig. 3 zeigt ein Beispiel der Beziehung zwischen einem eingebundenen Objekt und seiner Quelle.
Fig. 4 ist ein Blockdiagramm einer beispielhaften Instanz eines Objektes.
Fig. 5 zeigt ein Blockdiagramm einer öffentlichen Ansicht eines Objektes.
Fig. 6 zeigt ein Blockdiagramm eines typischen Beispiels der IMoniker-Schnittstelle.
Fig. 7 zeigt ein Blockdiagramm eines Verweisobjektes, welches in dem zusammengesetzten Dokument 303 der Fig. 3 mit der Zusammenfassung der Direktion gespeichert ist.
Fig. 8 zeigt ein Blockdiagramm einer typischen Objektdatenstruktur eines zusammengesetzten Verweisobjektes.
Fig. 9 ist ein Programmablaufplan einer Realisierung einer Methode für ein generisch zusammengesetztes Verweisobjekt, ComposeWith.
Fig. 10 ist ein Programmablaufplan für die Funktion MkCreateGenericComposite.
Fig. 11 ist ein Programmablaufdiagramm der FindLastEltMethode einer typischen Realisierung. Dieses Verfahren erzeugt zwei Verweisobjekte.
Fig. 12 ist ein Programmablaufplan für eine FindFirstElt Methode einer typischen Realisierung.
Fig. 13 ist ein Programmablaufdiagramm einer BindToObject Methode einer typischen Realisierung.
Fig. 14 ist ein Programmablaufdiagramm einer FindToObject Methode einer typischen Implementierung eines Verweisobjektes auf eine Datei.
Fig. 15 ist ein Programmablaufdiagramm einer BindToObject Methode einer typischen Realisierung eines Verweisobjektes auf einen Posten (Item).
Fig. 16 ist ein Programmablaufdiagramm einer BindToStorage Methode einer typischen Realisierung eines WItemMoniker.
Fig. 17 zeigt ein übergeordnetes Ablaufdiagramm einer reduzierten Methode (reduced method) für die Schnittstelle eines generischen zusammengesetzten Verweisobjektes.
Fig. 18 zeigt ein übergeordnetes Ablaufdiagramm der reduzierten Methode für eine typische Implementierung eines Verweisobjektes auf eine Datei.
Fig. 19 zeigt ein übergeordnetes Ablaufdiagramm eines reduzierten Verfahrens für eine typische Realisierung eines Verweisobjektes auf einen Posten einer Textverarbeitung WItemMoniker.
Fig. 20 zeigt ein übergeordnetes Ablaufdiagramm für die Funktion im MkParse-UserName.
Fig. 21 zeigt ein übergeordnetes Ablaufdiagramm für die Methode ParseUserName für eine typische Realisierung eines Verweisobjektes auf eine Datei.
Fig. 22 ist ein Diagramm, welches ein verbundenes Objekt erläutert.

Detaillierte Beschreibung der Erfindung

Die vorliegende Erfindung stellt ein verallgemeinertes Verfahren zur Namensgebung und zur Bindung von verbundenen Daten zur Verfügung. In einer bevorzugten Ausführungsform speichert ein zusammengesetztes Dokument, welches gebundene Daten umfaßt, eine beständige Datenkennung (Handle), welche "Verweisobjekt" genannt wird, welches einen Verweis auf die gebundene Quelle ist. Ein Verweisobjekt ist ein Datenobjekt, welches Information enthält, um die gebundenen Daten zu identifizieren und um Verfahren zur Verfügung zu stellen, mit denen ein Anwendungsprogramm an die gebundenen Daten anbinden kann.
Das Bindeverfahren gibt eine Instanz einer Schnittstelle zurück, durch die auf die gebundenen Daten zugegriffen werden kann. In einigen Fällen kann das Verweisobjekt die Daten binden, die selbst in einem anderen zusammengesetzten Dokument eingebettet sind. Z. B. kann ein Verweisobjekt an einen Bereich von Zellen innerhalb einer Tabelle eines Tabellenkalkulationsprogramms binden, wobei die Tabelle in einem Textdokument enthalten ist. Ein Verweisobjekt kann an Daten in irgendeiner Ebene innerhalb eines zusammengesetzten Dokuments binden. Während des Bindeprozesses können mehrere Anwendungen aufgerufen werden, um die gebundenen Daten aufzufinden. Z. B., um an den Bereich der Zellen innerhalb einer Tabellenkalkulation zu binden, die in einem Textdokument ist, kann das Textverarbeitungsprogramm aufgerufen werden, um eingebettete Tabellenkalkulationsdaten aufzufinden und das Tabellenkalkulationsprogramm kann aufgerufen werden, um den Bereich der Zellen zu binden.
Die vorliegende Erfindung definiert eine abstrakte Klasse (eine Schnittstelle) durch die auf ein Verweisobjekt zugegriffen wird. Typischerweise kann jedes Anwendungsprogramm, welches Daten zur Verfügung stellt, in ein zusammengesetztes Dokument eingebunden werden, das eine Implementierung der Verweisobjektschnittstelle unterstützt.
In einer bevorzugten Ausführung der vorliegenden Erfindung steuert ein Anwendungsprogramm, welches ein zusammengesetztes Dokument erzeugt, die Manipulierung der gebundenen oder eingebetteten Daten, die von anderen Anwendungen generiert wurden. In einer objektorientierten Ausdrucksweise werden diese Daten als ein Objekt bezeichnet. (Die Referenz BUDD, T., "An Introduction to Object-Oriented Programming," Addison-Wesley Publishing Co. Inc., 1991 bietet eine Einführung in objektorientierte Konzepte und Terminologie.) Ein Objekt, das entweder in ein zusammengesetztes Dokument gebunden oder eingebettet ist, ist "enthalten" (contained) in dem Dokument. Ein zusammengesetztes Dokument ist auch als ein "Behälter-" (container) Objekt bezeichnet und die Objekte, die in einem zusammengesetzten Dokument enthalten sind, werden als "enthaltene" (containee) Objekte bezeichnet. Mit Bezug auf die Fig. 1 und 2 sind die Planungsdaten 102 und Budgetdaten 103 enthaltene Objekte und das zusammengesetzte Dokument 101 ist ein Behälterobjekt. Der Benutzer kann dem Textverarbeitungsprogramm anzeigen, daß er ein enthaltenes Objekt bearbeiten will, wie z. B. die Budgetdaten 103. Wenn der Benutzer anzeigt, daß die Budgetdaten 103 bearbeitet werden sollen, entscheidet das Textverarbeitungsprogramm, welche Anwendung benutzt werden soll, um die Budgetdaten zu bearbeiten (z. B. das Tabellenkalkulationsprogramm) und startet die Anwendung. Der Benutzer kann dann die Budgetdaten mit der gestarteten Anwendung manipulieren und die Änderungen werden in dem zusammengesetzten Dokument widergespiegelt. Der gleiche Vorgang wird benutzt, egal ob die Budgetdaten als eingebettetes oder gebundenes Objekt gespeichert sind.
Fig. 3 ist ein Blockdiagramm, welches ein Beispiel eines zusammengesetzten Dokuments zeigt. Der wöchentliche Projektbericht 301 ist das gleiche zusammengesetzte Dokument wie in Fig. 1. Der Bericht der Zusammenfassung der Direktion 303 enthält eine Budgetgraphik 305, die an das wöchentliche Projekt 302 gebunden ist. Das wöchentliche Projekt 301 enthält eine eingebettete Tabellenkalkulation 302. Die eingebettete Tabellenkalkulation 302 wurde durch ein Tabellenkalkulationsprogramm 204 der Fig. 2 erzeugt. Die Daten für diese Tabellenkalkulation, das Budget für das Projekt, sind in dem Speicher des Berichts der wöchentlichen Projekte 301 abgespeichert, weil sie ein eingebettetes Objekt sind. Das Dokument mit der Zusammenfassung der Direktion 303 ist ein zusammengesetztes Dokument, welches natürlichen Text 304 und ein enthaltenes Objekt, die Budgetgraphik 305 enthält. Die Budgetgraphik 305 ist gebunden an die Daten, die in der Tabellenkalkulation 302 enthalten sind, welche in das zusammengesetzte Dokument 301 eingebettet sind.
In einer bevorzugten Ausführungsform kooperieren Anwendungsprogramme durch Nutzen von Objektbindung und eingebetteter Einrichtungen, um zusammengesetzte Dokumente zu erzeugen und zu manipulieren. Eine Anwendung, die ein zusammen gesetztes Dokument erzeugt, wird als Klientanwendung (client application) bezeichnet und eine Anwendung, die ein enthaltenes Objekt erzeugt und manipuliert, wird als Serveranwendung (server application) bezeichnet. Eine Anwendung kann sich entweder als Klient oder als Server verhalten. Mit Bezug auf Fig. 2 sind das Projektverwaltungsprogramm 201 und das Tabellenkalkulationsprogramm 204 Serveranwendungen und das Textverarbeitungsprogramm 206 ist eine Klientenanwendung. Eine Klientenanwendung ist für die Auswahl verschiedener Objekte innerhalb eines Behälterobjekts und für das Aufrufen der passenden Serveranwendung zum Manipulieren des ausgewählten enthaltenen Objekts verantwortlich. Eine Serveranwendung ist für die Manipulation des Inhalts der enthaltenen Objekte verantwortlich.
In einer bevorzugten Ausführungsform werden Anwendungen mit realisierungsunabhängigen Anwenderprogrammschnittstellen (API, application programming interface) versorgt, die die Funktionalität zum Einbinden und Einbetten von Objekten zur Verfügung stellt. Die API ist ein Satz von Funktionen, die aufgerufen werden durch Klienten- und Serveranwendungen. Diese Funktionen verwalten unter anderem die Installation und Initialisierung, die für Klientanwendungen notwendig ist, um Nachrichten und Daten zu senden und zu empfangen, an und von Serveranwendungen. Die API stellt Funktionen zur Verfügung, die die richtige Serveranwendung aufrufen, um auf ein bestimmtes enthaltenes Objekt zu reagieren und enthaltene Objekte zu manipulieren.
Zusätzlich definiert die API für Objekt-Bindung und -Einbetten "Schnittstellen" (interfaces), durch die Klientanwendungen mit ihren enthaltenen Objekten kommunizieren. Eine Schnittstelle ist ein Satz von Verfahren, welche gewissen Eingabe-, Ausgabe- und Verhaltensregeln folgen. Wenn ein enthaltenes Objekt eine bestimmte Schnittstelle unterstützt, kann die Klientanwendung die Verfahren dieser Schnittstelle aufrufen, um das definierte Verhalten zu bewirken. In einer bevorzugten Ausführungsform ist der Klientenanwendung der direkte Zugriff auf die Objektdaten nicht erlaubt; sie muß das Objekt mit den unterstützten Schnittstellen manipulieren. Eine Klientenanwendung ist an ein enthaltenes Objekt durch einen Zeiger auf eine Schnittstelle gebunden. Die Klientenanwendung greift auf das Objekt zu durch Aufrufen der Verfahren der Schnittstelle. Um auf die Objektdaten zuzugreifen, können die Verfahren Nachrichten an die Serveranwendungen schicken, um den spezifizierten Zugriff anzufordern. In einer bevorzugten Ausführungsform werden Nachrichten zwischen Klienten und Servern mit Mechanismen, die Interaktion verschiedener Prozesse erlauben (interprocess communications), die durch das zugrundeliegende Betriebssystem zur Verfügung gestellt werden, gesendet.
Ein Beispiel wird helfen, die Beziehung zwischen einem Klientenprozess und einem Serverprozess zu erläutern. Mit Bezug auf Fig. 1, wenn ein Benutzer Budgetdaten 103 des zusammengesetzten Dokuments 101 bearbeiten will, dann findet der folgende Ablauf von Ereignissen statt. Zuerst startet der Benutzer das Textverarbeitungsprogramm, welches dynamisch an die API für Objektbinden und -einbetten gebunden ist. Zweitens öffnet der Benutzer das zusammengesetzte Dokument zur Bearbeitung. Drittens wählt der Benutzer die Budgetdaten, welche in einem enthaltenen Objekt sind und zeigt an, daß das ausgewählte Objekt bearbeitet werden soll. Viertens ruft die Klientenanwendung eine API für Klientenroutinen auf, zum Ausführen eines Prozesses auf ein Objekt, welches der Routine eine Kennung (welche eindeutig das ausgewählte Objekt identifiziert) auf das Objekt und einen Merker (indicator) übergibt, daß der Prozess zu bearbeiten ist. Fünfttens, die API für Klientenroutinen bestimmt, daß das Tabellenkalkulationsprogramm die Prozesse für die Budgetdaten liefert. Sechstens startet die API für Klientencode das Tabellenkalkulationsprogramm als einen Serverprozess, wenn es noch nicht gestartet wurde. Siebtens sendet die Textverarbeitungsanwendung eine Nachricht an das Tabellenkalkulationsprogramm, daß es die Budgetdaten bearbeiten soll. Achtens empfängt die API für Servercode die Anforderung, zu editieren und ruft eine Routine in dem Tabellenkalkulationsprogramm auf, zum Bearbeiten der Daten. Wenn das Bearbeiten beendet ist, springt die Tabellenkalkulationsroutine zurück zu der API für Servercode. Die API für Servercode sendet eine Nachricht an die Textverarbeitungsanwendung, um anzuzeigen, daß das Bearbeiten beendet ist. Die API für Klientencode empfängt die Nachricht und kehrt von seinem Aufruf zurück. Nach Rückkehr von dem Aufruf weiß die Textverarbeitungsanwendung, daß das Bearbeiten beendet ist.
Zusätzlich zu den API für Klient und Server liefern die Einrichtungen für Objektbinden und -einbetten der vorliegenden Erfindung Information an Klient- und Serveranwendungen durch eine beständige globale "Registratur" (registry). Diese Registratur ist eine Datenbank von Informationen wie (1) für jeden Objekttyp, die Serveranwen dung, die den Objekttyp implementiert, (2) die Prozesse, die jede Serveranwendung an Klientanwendungen liefert, (3) wo die ausführbaren Dateien für jede Serveranwendung auffindbar sind und (4) ob jede Serveranwendung einen angegliederten Objekttreiber (object handler) hat.
In objektorientierter Ausdrucksweise ist eine Schnittstelle eine "abstrakte Klasse": eine Klasse mit einer Definition seiner Daten und Verfahren, aber mit keiner Implementierung für diese Verfahren. Es ist die Verantwortung der Serveranwendung für das Objekt "Klasse" den tatsächlichen Code zu liefern, für die Verfahren, die zum Manipulieren des Objekts zur Verfügung stehen.
Fig. 4 ist ein Blockdiagramm einer beispeilhaften Instanz eines Objektes. In einer bevorzugten Ausführungsform entspricht der Plan eines Beispiels dem Modell, welches in dem US-Patent mit dem Titel "A Method for Implementing Virtual Functions and Virtual Bases in a Compiler for an Object-Oriented Programming Language" definiert ist.
Das Beispiel enthält Objektdatenstruktur 401 und Schnittstellendatenstruktur 413 für jede unterstützte Schnittstelle. Die Objektdatenstruktur 413 enthält Zeiger 402 auf Schnittstellendatenstrukturen 413 und kann private Daten des Beispiels enthalten. Die privaten Daten dieses Stichprobenbeispiels umfassen einen Klassenbezeichner (class identifier) 403, Kennung 404 für den Speicher des Objekts und Daten 405 zum Folgen des Zustandes des Objektes. Der Klassenbezeichner benutzt, um auf die entsprechende Serveranwendung für das Objekt zuzugreifen. Es ist eine Datenstruktur "Typ" (type), die in Programmiersprachen benutzt wird. Die Schnittstelle kann den Server für das Objekt bestimmen, durch Nutzen der CLASS_ID als einen Index in die beständige globale Registratur. Wie in Fig. 4 gezeigt, enthält jede Schnittstellendatenstruktur 413 eine private Datenstruktur 406 und eine Tabelle virtueller Funktionen 408. Die private Datenstruktur 406 enthält einen Zeiger 407 auf die Tabelle virtueller Funktionen 408. Die Tabelle virtueller Funktionen 408 enthält Zeiger auf den Code, der die Verfahren der Schnittstelle implementiert.

Tabelle 1

Definieren der Klasse Schnittstelle
interface intf {public:
virtual RETCODE pfnc&sub1; (arg1, arg2) = 0;
virtual RETCODE pfnc&sub2; (arg1, arg2) = 0;
virtual RETCODE pfnc3 () = 0;
};
Tabelle 1 stellt die Definition für die Schnittstelle für den ersten Eintrag printf&sub1; in die Objektdatenstruktur 401 dar. In Tabelle 1 bedeutet das Wort "Interface" eine C++ Klasse. Die Definition zeigt drei Methoden mit ihren Argumenten. Das " = 0" am Ende jeder Liste von Argumenten zeigt, daß die Methode keine Implementierung mit Code hat. In der C++ Programmiersprache werden diese Funktionen als "reine virtuelle Funktionen" (pure virtual functions) bezeichnet. Eine Klasse, die nur aus reinen virtuellen Funktionen besteht, wird als abstrakte Klasse bezeichnet.
Fig. 5 ist ein Blockdiagramm, das einen öffentlichen Blick (public view) des Objekts zeigt. Ein öffentlicher Blick eines Objekts sind die verschiedenen Schnittstellen, die das Objekt unterstützt 502-506. Jede Schnittstelle liefert Methoden, mit denen Klientanwendungen auf Objekte zugreifen können. Jedes Objekt unterstützt eine IUnknown Schnittstelle 502. Anwendungen benutzen die IUnknown Schnittstelle 502, um festzustellen, welche anderen Schnittstellen das Objekt unterstützt. Die Implementierung der IUnknown Schnittstelle 502 für ein bestimmtes Objekt weiß, welche anderen Schnittstellen sie unterstützt und meldet der aufrufenden Anwendung Zeiger auf diese Schnittstellen zurück. In einer bevorzugten Ausführungsform wird die Methode IUnknown::QueryInterface für diesen Zweck benutzt. Schnittstellen 503 bis 506 sind Beispiele typischer Schnittstellen, die von einem Objekt unterstützt werden können. Z. B. die ICreate Schnittstelle 503 stellt Methoden zum Erzeugen einer neuen Instanz eines Objektes zur Verfügung. Die IContainer Schnittstelle 504 stellt Methoden zum Auflisten der enthaltenen Objekte zur Verfügung, die in einem Objekt enthalten sind. Die IDataClientSite Schnittstelle 505 liefert Methoden, die von Servern zum Kommunizieren mit Behälterobjekten benutzt werden sollen. Die IDataObjekt Schnittstelle 506 stellt Methoden zum Manipulieren von Objektdaten zur Verfügung.
Fig. 6 ist ein Bockdiagramm, welches ein typisches Beispiel der IMoniker Schnittstelle zeigt. Anhang A enthält eine detaillierte Beschreibung der Methoden der IMoniker Schnittstelle. Die Instanz Datenstrukturen umfaßt Objektdatenstruktur 601 und die Tabelle virtueller Funktionen 603. Die Objektdatenstruktur 601 enthält einen Zeiger 602 auf die Tabelle virtueller Funktionen 603 und private Instanzdaten. Die Tabelle virtueller Funktionen 603 enthält Zeiger auf den Code, der die Methode der IMoniker Schnittstelle implementiert. Tabelle 2 ist die Definition der Klasse für die IMoniker Schnittstelle. Tabelle 2
Zusätzlich zu diesen Methoden unterstützt eine IMoniker Implementierung typischerweise die Funktionen MkParseUserName, MkCreateIBindContext, MkCreate- GenericComposite, MkCreateFileMoniker, MkCreate4ItemMoniker und MkCreateAntiMoniker, die nachstehend definiert sind.
Fig. 22 ist ein Diagramm, welches ein gebundenes Objekt erläutert. In diesem Beispiel ist das zusammengesetzte Dokument 2201 eine Zusammenstellung verschiedener Projektberichte, wie der Bericht, der im zusammengesetzten Dokument 101 gespeichert ist. Zusammengesetztes Dokument 2201 enthält einen Verweis auf das zusammengesetzte Dokument 2202. Der Verweis zeigt an, daß das zusammengesetzte Dokument, welches in der Datei "VAC1.DOC" gespeichert ist, logisch in dem zusammengesetzten Dokument 2201 ist. In einer bevorzugten Ausführungsform ist der Verweis als ein Verweisobjekt (Moniker) gespeichert. Ein Verweisobjekt ist eine Instanz einer Klasse (ein Objekt des Typs Verweisobjekt), die Verfahren bereitstellt zum Zugreifen auf die Quelle des Verweises. Ein Objekt des Typs Verweisobjekt verkapselt Daten, die die Verweisquelle identifizieren und liefert Methoden, durch die ein Anwendungsprogramm auf die Verweisquelle zugreifen kann. Z. B. wenn der Verweis vom zusammengesetzten Dokument 2201 zum zusammengesetzten Dokument 2202 erzeugt wird, ruft das Textverarbeitungsprogramm eine Funktion auf, um das Objekt des Typs Verwaltungsobjekt, welches auf die Datei "VAC1.DOC" zeigt, zu instantiieren. Die Funktion gibt einen Zeiger auf das neue Objekt des Typs Verweisobjekt zurück. Das Textverarbeitungsprogramm speichert dann das Objekt des Typs Verweisobjekt in dem zusammengesetzten Dokument 2201. Das Textverarbeitungsprogramm greift auf die Verweisquelle mit den Methoden des Objekts des Typs Verweisobjekt zu. Z. B. die Klasse Verweisobjekt unterstützt eine "bind"-Methode. Die bind-Methode bestimmt, wo die Verweisquelle auffindbar ist und gibt einen Zeiger auf ein Objekt, welches die Quelle darstellt, zurück. In diesem Beispiel würde die bind-Methode des Objekts des Typs Verweisobjekt bestimmen, daß die Quelle in der Datei "VAC. DOC" gespeichert ist, ein Objekt, welches die Datei darstellt, instantiieren und einen Zeiger auf das instantiierte Objekt zurückgeben. Das Textverarbeitungsprogramm könnte dann die Methoden des zurückgegebenen Dateiobjekts aufrufen, um auf die Quelldaten zuzugreifen.
Fig. 7 ist ein Blockdiagramm, welches das Verweisobjekt zeigt, das in dem zusammengesetzten Dokument mit der Zusammenfassung der Direktion 303 der Fig. 3 gespeichert ist. Das Verweisobjekt stellt ein gebundenes Grafikobjekt 305 dar. Weil der Verweis auf Daten zeigt, die in einem zusammengesetzten Dokument eingebettet sind, wird das Verweisobjekt als eine Zusammensetzung eines Verweises, der benötigt wird, um das zusammengesetzte Dokument zu identifizieren, und einem Verweis, der benötigt wird, um die Daten in dem zusammengesetzten Dokument zu identifizieren, dargestellt. Der Verweis wird als ein zusammengesetztes Verweisobjekt bezeichnet. Ein zusammengesetztes Verweisobjekt enthält Verweisobjektkom ponenten, die in einer linken oder rechten Art in einer eingebetteten Hierarchie angeordnet sind. Das zusammengesetzte Verweisobjekt 701 umfaßt drei Verweisobjektkomponenten 702, 703 und 704. Verweisobjektkomponente 702 weist auf das zusammengesetzte Dokument 301 hin. Verweisobjektkomponente 702 enthält eine CLASS_D (FileMoniker), ein durch den Benutzer lesbaren Namen "C:\VAC1.DOC" des zusammengesetzten Dokuments 301. Verweisobjektkomponente 703 weist auf das eingebettete Objekt des zusammengesetzten Dokuments 301 hin. Die Textverarbeitungsanwendung versteht Verweisobjektkomponente 703 und benutzt sie, um die eingebettete Tabellenkalkulation aufzufinden. Verweisobjektkomponente 703 enthält CLASS_ID (WItemMoniker) und einen, durch ein Benutzer lesbaren Namen, der eingebetteten Tabellenkalkulation. Die CLASS_ID "WItemMoniker" zeigt an, daß das Textverarbeitungsprogramm die Verweisobjektkomponente erkennt. Verweisobjektkomponente 704 weist auf den Bereich von Daten in dem Objekt der eingebetteten Tabellenkalkulation 302 hin. Verweisobjektkomponente 704 enthält CLASS_ID (SItemMoniker) und einen durch den Benutzer lesbaren Namen für den Bereich. Die CLASS_ID "SItemMoniker" zeigt an, daß das Tabellenkalkulationsprogramm die Verweisobjektkomponente erkennt. Die Datenstruktur des zusammengesetzten Verweisobjektes umfaßt Datenstruktur 801 und die Tabelle virtueller Funktion 802. Datenstruktur 801 enthält die CLASS_ID 803 und einen Zeiger 804 auf die verkettete Liste 805. In diesem Beispiel zeigt die CLASS_ID auf ein Verweisobjekt des Typs ID_GenCompositeMoniker.
Fig. 8 ist ein Blockdiagramm, welches eine typische Datenstruktur eines zusammengesetzten Verweisobjektes zeigt. Die verkettete Liste 805 enthält einen Eintrag 806 für jede Verweisobjektkomponente. Jeder Eintrag enthält einen Zeiger auf die Verweiskomponente 809 bis 811.
Fig. 9 ist ein Programmablaufplan einer Implementierung der Methode ComposeWith des generischen zusammengesetzten Verweisobjektes. Die Methode GenCompositeMoniker::ComposeWith erzeugt ein neues zusammengesetztes Verweisobjekt mit dem spezifizierten Verweisobjekt als den linken Teil und dem ernannten Verweisobjekt als den rechten Teil des neuen zusammengesetzten Verweisobjektes. Diese Methode gibt einen Zeiger auf das neue zusammengesetzte Verweisobjekt zurück. Im Schritt 901 ruft die Methode die IsGenericComposite? Methode des ernannten Verweisobjektes auf, um zu bestimmen, ob es ein generisches zusammengesetztes Verweisobjekt ist. Wenn es keines ist, fährt die Methode am Schritt 904 fort, ansonsten fährt sie mit Schritt 902 fort. In Schritt 902 ruft die Methode die FindFirstElement Methode des ernannten Verweisobjektes auf, welche einen Zeiger auf die erste Verweisobjektkomponente und einen Zeiger auf den Rest der Verweisobjektkomponenten zurückgibt. In Schritt 904 zieht die Funktion die CLASS_ID des ernannten Verweisobjektes heraus. Wenn die Schritte 903 und 904 beendet sind, hat die Methode die CLASS_ID des Verweisobjektes erhalten, welche sie als den rechten Teil des neuen zusammengesetzten Verweisobjektes nutzen wird. Im Schritt 907 ruft die Methode die MkCreateGenericComposite Funktion auf, um ein durch ein generisches zusammengesetztes Verweisobjekt spezifiziertes Verweisobjekt in dem linken Teil und das ernannte Verweisobjekt in dem rechten Teil zu erzeugen und dann gibt die Methode einen Zeiger auf das neue zusammengesetzte Verweisobjekt zurück.
Fig. 10 ist ein Programmablaufdiagramm für die Funktion MkCreateGenericComposite. Diese Funktion nimmt zwei Verweisobjekte, ein linkes und ein rechtes, erzeugt ein neues zusammengesetztes Verweisobjekt, welches das linke und rechte Verweisobjekt umfaßt, und gibt einen Zeiger auf das neue Verweisobjekt zurück. Im Schritt 1001 ruft die Funktion die pmkFirst::IsGenericComposite? Methode auf, um zu bestimmen, ob das linke Verweisobjekt ein generisches zusammengesetztes Verweisobjekt ist. Wenn es eins ist, fährt die Funktion mit Schritt 1004 fort, ansonsten fährt sie mit Schritt 1002 fort. In den Schritten 1002 und 1004 weist die Funktion die notwendigen Datenstrukturen zu und weist einen neuen generischen zusammengesetzten Verweisobjektknotenpunkt (generic composite moniker node) in der verketteten Liste zu und speichert diesen Wert in der vorherigen Variable. Im Schritt 1003 fügt die Funktion das Verweisobjekt auf der linken Seite, welches in (pmkFirst) weitergegeben wurde, in das erste Element in dem neuen zusammengesetzten Verweisobjekt ein, auf das durch pcm gezeigt wird. Die Methode wird mit Schritt 1008 fortgesetzt. In Schritt 1004 bis 1007 führt die Funktion Schleifen aus, um ein neues zusammengesetztes Verweisobjekt zu erzeugen, welches die Verweisobjektkomponenten des ursprünglichen linken Verweisobjektes enthält. Die Schleife durchquert die Elemente der verketteten Liste des ursprünglichen linken Verweisobjektes und fügt eine Kopie der Verweisobjektkomponenten in das neue zusammengesetzte Verweisobjekt ein. Im Schritt 1004 initialisiert die Funktion mehrere Variablen, um nach dem letzten Element des linken Verweisobjektes zu suchen. Um dies zu tun setzt sie die vorherige Variable, um auf das erste Element der verketteten Liste zu zeigen, die aktuelle Variable auf das zweite Element der verketteten Liste und pcm auf das erste Verweisobjekt, auf das durch das erste Element der verketteten Liste gezeigt wird. In Schritt 1005 bestimmt die Funktion, ob die aktuelle Variable NULL ist. Wenn sie NULL ist, dann zeigt die vorherige Variable auf das letzte Element in dem linken zusammengesetzten Verweisobjekt, welches anzeigt, daß all die Verweisobjektkomponenten in dem neuen zusammengesetzten Verweisobjekt ungültig waren und die Funktion fährt mit dem Schritt 1008 fort, ansonsten fährt die Funktion mit dem Schritt 1006 fort. In Schritt 1006 ruft die Funktion die Methode Compose- With des Verweisobjektes auf, auf das durch die Variable pcm gezeigt wird und gibt sie an das Verweisobjekt, auf das durch die aktuelle Variable gezeigt wird, weiter. In Schritt 1007 setzt die Funktion eine Variable pcm, um auf dieses neue zusammengesetzte Verweisobjekt zu zeigen und aktualisiert die vorherige und aktuelle Variable, um auf die nächsten zwei Elemente in der verketteten Liste zu zeigen und wiederholt Schritt 1005, um zu bestimmen, ob die vorherige Variable auf das Ende der verketteten Liste zeigt. In Schritt 1008 ruft die Funktion die Methode pmkRestIsGenericComposite? auf, um zu bestimmen, ob das rechte Verweisobjekt ein generisches zusammengesetztes Verweisobjekt ist. Wenn es keines ist, fährt die Funktion mit Schritt 1010 fort, ansonsten fährt sie mit Schritt 1009 fort. In Schritt 1009 hängt die Funktion die verkettete Liste des rechten Verweisobjektes an das neue linke Verweisobjekt an. Die Funktion fährt dann mit Schritt 1012 fort. In Schritten 1010 und 1011 hängt die Funktion ein neues Element, welches auf das rechte Verweisobjekt zeigt, an das neue linke Verweisobjekt an. In Schritt 1012 setzt die Funktion den Rückgabewert ppmkComposite auf die pcm, das neue zusammengesetzte Verweisobjekt, und kehrt zurück.
Fig. 11 ist ein Programmablaufdiagramm einer FindLastElt Methode einer typischen Ausführungsform. Diese Methode erzeugt zwei Verweisobjekte. Das erste Verweisobjekt entspricht der letzten Verweisobjektkomponente in dem spezifizierten Verweisobjekt. Das zweite Verweisobjekt entspricht dem Rest des spezifizierten Verweisobjektes. In Schritt 1101 setzt die Methode die Variabel Aktuell (current), um auf das zweite Element in der verketteten Liste zu zeigen, die Variable Vorher (previous) auf das erste Element der verketteten Liste und die Variable Rest, so das sie auf die erste Verweisobjektkomponente zeigt. Schritte 1102 bis 1105 durchlaufen die Verkettete Liste des spezifizierten Verweisobjektes zum Erzeugen des zweiten Verweisobjektes. In Schritt 1102, wenn die Variable Aktuell auf das letzte Element zeigt, fährt die Methode mit Schritt 1106 fort, ansonsten fährt die Methode mit Schritt 1103 fort. In Schritt 1106 setzt die Methode den Parameter LastElt, um auf das Verweisobjekt, auf das durch die Variable Aktuell gezeigt wird, zu zeigen und kehrt zurück.
Fig. 12 ist ein Programmablaufdiagramm für die FindFirstElt Methode einer typischen Ausführung. Diese Methode entspricht der FindLastElt Methode, aber gibt einen Zeiger auf die erste Verweisobjektkomponente und einen Zeiger auf ein neues zusammengesetztes Verweisobjekt, welches die restlichen Verweisobjektkomponenten umfaßt, zurück.
Fig. 13 ist ein typisches Programmablaufdiagramm der BindToObject Methode für eine typische Ausführung. Die Methode BindToObject ruft rekursiv entweder Bind- ToObject (oder BindToStorage) auf, um ein Objekt (oder Speicherung) zu erhalten, welches benutzt werden kann, um das Objekt, welches durch das spezifizierte Verweisobjekt angezeigt wird, zu orten und zu binden. Im allgemeinen gibt die Bind- ToObject Methode das Objekt oder die Speicherung zurück, welche durch das spezifizierte Verweisobjekt angezeigt wird, durch Benutzen der Methode seiner Verweisobjektpräfixkomponente (prefix component moniker). Diese Methode ruft die BindToObject Methode der letzten Verweisobjektkomponente auf, welche wiederum die BindToObject Methode eines Präfixverweisobjektes auf einer rechten oder linken Art aufruft. Die BindToObject Methode nimmt sechs Parameter: ein pointer-to-a-bind Kontext, den Schnittstellenbezeichner (interface identifier) des dritten Parameters, den Zeiger auf eine Schnittstelle des Objektes, welches dem Präfixverweisobjekt entspricht, das Präfixverweisobjekt, die Schnittstelle an die der Aufrufer anbinden will, und einen Ausgabeparameter, der der instantiierten Schnittstelle entspricht. In Schritt 1301 ruft die Methode die FindLastElt Methode des spezifizierten Verweisobjektes auf, um seine letzte Verweisobjektkomponente zu finden. In Schritt 1302 ruft die Methode die lidBindToObject Methode der letzten Verweisobjektkomponente auf. In Schritt 1303, wenn diese Methode ID_NULL zurückgibt, dann muß die BindToObject Methode der letzten Verweisobjektkomponente aufgerufen werden, um die Schnittstelle zu bestimmen, die für das Binden benötigt wird und die Methode fährt am Schritt 1304 fort, ansonsten fährt die Methode am Schritt 1305 fort. In Schritt 1304 ruft die BindToObject Methode die BindToObject Methode der letzten Verweisobjektkomponente auf und gibt sie an den ersten Teil des zusammengesetzten Verweisobjektes als Präfixverweisobjekt weiter und kehrt zurück. In Schritt 1205, wenn die Schnittstelle, die von der lidBindToObject Methode der letzten Verweisobjektkomponente zurückgegeben wurde, gleich ID_STORAGE ist, dann fährt die Methode mit Schritt 1306 fort, ansonsten fährt sie mit Schritt 1307 fort. In Schritt 1306 ruft die Methode die BindToStorage Methode des Präfixverweisobjektes (Variable Rest) auf. Wenn sie zurückkehrt, zeigt Variable pv auf eine gebundene Instanz des Speicherungsobjektes (storage object), welches dem Präfixverweisobjekt entspricht, und fährt mit Schritt 1308 fort. In Schritt 1307 ruft die Methode statt dessen die Bind- ToObject Methode an dem Präfixverweisobjekt auf. In diesem Fall gibt sie die Schnittstelle, die durch die letzte Verweisobjektkomponente angefordert wurde, weiter und das instantiierte Objekt, welches der Schnittstelle entspricht, wird in der Variable pv zurückgegeben. In Schritt 1308 wird das instantiierte Objekt, auf das durch die Variable pv gezeigt wird, in dem hineingereichten Bindekontext registriert. Der Bindekontext ist eine verkettete Liste, momentan instantiierter Objekte entsprechend durch vorherige Aufrufe der BindToObject Methode gebunden. Der Bindekontext wird durch die BindToObject Methoden benutzt, um zu bestimmen, ob das Objekt, auf das durch das spezifizierte Verweisobjekt Bezug genommen wird, schon instantiiert ist. In Schritt 1309 ruft die Methode die BindToObjekt Methode für die letzte Verweisobjektkomponente auf, mit der Schnittstelle, die durch die letzte Verweisobjektkomponente angefordert wurde, der instantiierten Schnittstelle entsprechend des Präfixverweisobjektes und die ursprüngliche Schnittstelle, die in dem ursprünglichen BindToObject Aufruf angefordert wurde. Die Methode kehrt dann zurück.
Fig. 14 ist ein Programmablaufdiagramm der BindToObjekt Methode für eine typische Ausführung des Dateiverweisobjektes. Diese Methode bestimmt, ob ein Objekt, entsprechend einem spezifizierten Dateiverweisobjekt, welches durch eine Tabelle von laufenden Objekten (running object table) angezeigt wird, existiert und gibt einen Zeiger auf das Objekt zurück. Die Tabelle laufender Objekte enthält Zeiger auf alle momentan instantilerten Objekte. Ansonsten ortet diese Methode den entsprechenden Server und instantiiert eine Schnittstelle zu der Datei. Die FileMoniker::BindToObject Methode nimmt die gleichen sechs Parameter, wie die BindToOb ject Methode für generische zusammengesetzte Verweisobjekte. In den Schritten 1401 bis 1404 benutzt die Methode die Tabelle laufender Objekte, die einem Objekt entspricht, um zu bestimmen, ob das spezifizierte Dateiverweisobjekt existiert. In Schritt 1401 bestimmt die Methode, ob das spezifizierte Dateiverweisobjekt in der Tabelle laufender Objekte aufgeführt ist. Wenn es aufgeführt ist, fährt die Methode mit Schritt 1402 fort, ansonsten fährt sie mit Schritt 1405 fort. In Schritt 1402 bestimmt die Methode, ob die angeforderte Schnittstelle mit der in der Tabelle laufender Objekte übereinstimmt. Wenn sie übereinstimmt, dann gibt die Methode in Schritt 1403 einen Zeiger auf die Schnittstelle zurück. Ansonsten erhält die Methode in Schritt 1404 die angeforderte Schnittstelle durch Aufrufen der QueryInterface Methode des Objektes, welches in der Tabelle laufender Objekte gefunden wurde, und kehrt zurück. In Schritt 1405, weil das spezifizierte Verweisobjekt nicht in der Tabelle laufender Objekte gefunden wurde, findet diese Methode den Server, der dem spezifizierten Verweisobjekt (Dateiname) entspricht. In Schritt 1406 ruft die Methode den Server, um eine Instanz ihrer Klasse zu erzeugen. In Schritt 1407 ruft die Methode die QueryInterface Methode dieser Instanz, um eine Schnittstelle zum Binden zu erhalten. In Schritt 1408 ruft die Methode die Load Methode der Bindungsschnittstelle und kehrt zurück.
Fig. 15 ist ein Programmablaufdiagramm der BindToObject Methode für eine typische Implementierung eines Postenverweisobjektes (ItemMoniker). In dem vorigen Beispiel haben WItemMoniker und SItemMoniker beide ähnliche Implementierungen. Diese Methode benutzt das Schnittstellenobjekt des Präfixverweisobjektes, um seine GetObject Methode aufzurufen. Die GetObject Methode ortet und bindet die Instanz des Objektes, welche durch das Postenverweisobjekt angezeigt wird. Diese Methode nimmt die gleichen sechs Parameter, die an die BindToObject Methode des generischen zusammengesetzten Verweisobjektes gegeben werden. In Schritt 1501 bestimmt die Methode, ob ein Objekt zum Binden weitergegeben wurde. Wenn eins weitergegeben wurde, fährt die Methode mit seinem Schritt 1502 fort, ansonsten fährt sie mit Schritt 1503 fort. In Schritt 1502 ruft die Methode die GetObject Methode der Schnittstelle, die an sie gegeben wurde auf, um das Objekt, welches durch das Postenverweisobjekt angezeigt wurde, zu instantiieren, und kehrt dann zurück. In Schritt 1503, wenn das Präfixverweisobjekt nicht NULL ist, fährt die Methode mit Schritt 1504 fort, ansonsten kehrt sie zurück. In Schritt 1504 ruft die Methode die BindToObject Methode des Präfixverweisobjektes auf, um die IContainer Schnittstelle anzufordern. Im Schritt 1505 ruft die Methode die GetObject Methode der angeforderten IContainer Schnittstelle auf und kehrt zurück.
Fig. 16 ist ein Programmablaufdiagramm der BindToStorage Methode einer typischen Implementierung von WItemMoniker. Diese Methode ruft die BindToStorage Methode seines Präfix auf und dann, sobald sie die Speicherungskennung (storage handle) für das Präfix erhalten hat, bekommt sie die Speicherung, die mit dem spezifizierten Verweisobjekt verbunden wird. In Schritt 1601 bestimmt die Methode, ob das hineingereichte Präfix NULL ist und, wenn NULL ist, kehrt die Methode zurück, ansonsten fährt die Methode mit ihrem Schritt 1602 fort. In Schritt 1602 ruft die Methode die BindToStorage Methode des Präfixverweisobjektes auf und gibt ihr die angeforderte Schnittstelle. In Schritt 1603 ruft diese Methode die GetToStorage Methode der Speicherungsschnittstelle, die in Schritt 1602 zurückgegeben wurde, auf und gibt ihr den einzigartigen Bezeichner für das Objekt, welches in dem aktuellen WItemMoniker spezifiziert ist. Die Methode kehrt dann zurück.
Fig. 17 ist ein übergeordnetes Ablaufdiagramm für die Reduce Methode für die GenericCompositeMoniker Schnittstelle. Diese Routine versucht, jede Verweisobjektkomponente zu reduzieren durch Aufrufen der Reduce Methode jeder Verweisobjektkomponente und setzt ein neues GenericComponsiteMoniker aus den reduzierten Komponenten zusammen. Die Methode nimmt drei Parameter: einen Zeiger auf einen Bindekontext, ein Präfixverweisobjekt und einen Ausgabeparameter für das reduzierte Verweisobjekt (reduced Moniker). In Schritt 1701 findet die Methode das erste Element in der verketteten Liste von Verweisobjektkomponenten, die das spezifizierte Verweisobjekt zusammensetzen. In Schritten 1702 bis 1709 ruft die Methode wiederholt die reduzierte Methode jeder Verweisobjektkomponente auf und erzeugt ein neues zusammengesetztes Verweisobjekt mit den reduzierten Komponenten. In Schritt 1702, wenn alle Elemente der verketteten Liste verarbeitet wurden, fährt die Methode mit Schritt 1703 fort, ansonsten fährt sie mit Schritt 1704 fort. In Schritt 1703 setzt die Methode die Ausgabeparameter auf die neuen reduzierten zusammengesetzten Verweisobjekte und kehrt zurück. In Schritt 1704 ruft die Methode die Reduce Methode der Verweisobjektkomponente auf, auf die durch die Variable M Element gezeigt wird, übergibt den Bindekontext und einen Zeiger auf das Präfix verweisobjekt. Das Präfixverweisobjekt entspricht dem neuen zusammengesetzten Verweisobjekt, das soweit erzeugt wurde. In Schritt 1705, wenn die Methode bestimmt, daß die Variable, die auf das Präfixverweisobjekt zeigt, NULL ist, fährt sie mit Schritt 1706 fort, ansonsten fährt sie mit Schritt 1707 fort. In Schritt 1706, wenn die Variable, die auf das Präfixverweisobjekt zeigt, auf NULL zeigt (was bei der ersten Schleife passiert), wird sie auf die reduzierte Verweisobjektkomponente gesetzt, die in Schritt 1704 zurückgegeben wurde und die Methode fährt mit Schritt 1709 fort. In Schritt 1707, wenn die Variable, die auf das Präfixverweisobjekt zeigt, nicht NULL ist, ruft die Methode die ComposeWith Methode des Präfixverweisobjektes auf, um die Präfix mit dem neuen reduzierten Verweisobjekt, das in Schritt 1704 zurückgegeben wurde, zusammen zu setzen. In Schritt 1708 wird die Variable, die auf das Präfixverweisobjekt zeigt, zurück auf das neue zusammengesetzte Ergebnis gesetzt, welches alle die Verweisobjektreduzierungen enthält, die stattgefunden haben. In Schritt 1709 wird die Variable auf das nächste Element der verketteten Liste von Verweisobjektkomponenten vorgeschoben und die Methode kehrt zum Schritt 1702 am oberen Ende der Schleife zurück.
Fig. 18 ist ein Programmablaufdiagramm der Reduce Methode für eine typische Implementierung eines Dateiverweisobjektes. Die Reduce Methode untersucht das Präfixverweisobjekt, welches ihr übergeben wurde und bestimmt, ob die letzte Komponente des Präfixverweisobjektes ein weiteres Dateiverweisobjekt ist. Wenn es ein weiteres Dateiverweisobjekt ist, gibt diese Methode ein neues zusammengesetztes Dateiobjekt zurück, welches die Kombination der zwei Dateiverweisobjekte in einem ist. Es entfernt auch das Dateiverweisobjekt, welches es von dem übergebenen Präfix verbraucht hat. Diese Funktion nimmt drei Parameter: einen Zeiger auf eine Bindekontext, einen Zeiger auf das Präfixverweisobjekt und einen Ausgabeparameter, wo das neu reduzierte Verweisobjekt zurückgegeben wird. In Schritt 1801 untersucht die Funktion das überreichte Präfixverweisobjekt, um festzustellen, ob es NULL ist. Wenn es NULL ist, kehrt die Funktion zurück, ansonsten fährt sie mit Schritt 1802 fort. In Schritt 1802 untersucht die Funktion das Präfixverweisobjekt, um festzustellen, ob es ein generisches zusammengesetztes Verweisobjekt ist. Wenn es eins ist, fährt die Funktion mit Schritt 1804 fort, ansonsten fährt sie mit Schritt 1803 fort. In Schritt 1803 setzt die Funktion das letzte Element auf das Präfixverweisobjekt, weil das Präfix ein einfacheres Verweisobjekt ist und fährt mit Schritt 1805 fort. In Schritt 1804 ruft die Funktion die FindLastElt Methode des Präfixverweisobjektes auf, um das letzte Element des zusammengesetzten Präfixverweisobjektes zu erhalten. In Schritt 1805 wird die CLASS_ID des letzten Elementes überprüft, um festzustellen, ob es ein Dateiverweisobjekt ist. Wenn es keines ist, fährt die Funktion mit Schritt 1806 fort, ansonsten fährt sie mit Schritt 1807 fort. In Schritt 1806 setzt die Funktion die Ausgabeparameter auf sich selbst, weil keine Reduzierung stattgefunden hat und kehrt zurück. In Schritt 1807 hängt die Funktion den Dateiname, der mit diesem Verweisobjekt verbunden wird, an den Dateinamen des Verweisobjektes, auf das durch das letzte Element gezeigt wird, an. Als nächstes ruft die Funktion im Schritt 1808 ihre eigene Create Methode mit dieser neuen Zeichenkette (string) des Dateinamens auf In Schritt 1809 setzt sie die Präfix mit dem was die Präfix ohne dem letzten Element war, gleich, oder auf NULL, wenn die Präfix kein zusammengesetztes Verweisobjekt war. In Schritt 1801 setzt die Funktion die Ausgabeparameter entsprechend dem neu reduzierten Verweisobjekt auf das in Schritt 1808 erzeugte Verweisobjekt, und die Funktion kehrt zurück.
Fig. 19 zeigt ein übergeordnetes Programmablaufdiagramm der Reduce Methode für eine typische Implementierung des Verweisobjektes eines Textverarbeitungspostens (Word Processing Item Moniker) WItemMoniker. Diese Routine gibt eine spezielle Art von Verweisobjekt zurück, ein Speicherungsverweisobjekt (storage moniker), welches durch die BindToObject Methode benutzt werden kann, um den Server für ein eingebettetes Objekt direkt aufzurufen, wodurch das Aufrufen der Textverarbeitungsanwendung umgangen wird. Dies wird erreicht durch untersuchen einer speziellen Objekttabelle, die in dem Textverarbeitungsdokument enthalten ist, um den passenden Speicherungszeiger (storage pointer) für das eingebettete Objekt zu finden. Dieser Speicherungszeiger wird dann in einem Speicherungsverweisobjekt zusammengesetzt und anhand seiner BindToObject Methode, die aufgerufen wurde, kann es feststellen, welcher Server aufgerufen werden soll. Diese Routine nimmt drei Parameter: einen pointer-to-a-bind Kontext, ein Präfixverweisobjekt und einen Ausgabeparameter, der das neue reduzierte Verweisobjekt enthalten wird. In Schritt 1901 stellt die Methode fest, ob die Präfix NULL ist und wenn sie NULL ist, kehrt sie zurück, ansonsten fährt die Methode mit Schritt 1902 fort. In Schritt 1902 stellt die Methode fest, ob die Präfix ein generisches zusammengesetztes Verweisobjekt ist und wenn es eins ist, fährt sie mit Schritt 1903 fort, ansonsten fährt sie mit Schritt 1904 fort. In Schritt 1903 ruft die Funktion die FindLastElt Methode des Präfixverweisobjektes auf, um einen Zeiger-auf-letztes-Verweisobjekt der verketteten Liste zu erhalten. Sie fährt dann mit Schritt 1905 fort. Im Schritt 1904 setzt die Methode den Zeiger für das letzte Element auf die Präfix, weil sie kein zusammengesetztes Verweisobjekt ist. In Schritt 1905 untersucht die Methode die CLASS_ID des letzten Elements, um festzustellen, ob es ein Dateiverweisobjekt ist. Wenn es keines ist, fährt die Funktion mit Schritt 1906 fort, ansonsten fährt sie mit Schritt 1907 forL In Schritt 1006 gibt die Funktion einfach sich selbst in dem Ausgabeparameter zurück, weil keine Reduzierung möglich war. In Schritt 1907 untersucht die Methode die Dateikennung (File Extension), oder andere Merkmale, die sie kennt, um festzustellen, ob die Datei der Textverarbeitungsanwendung angehört. Wenn sie feststellt, daß der Typ der Datei unbekannt ist, fährt die Funktion mit Schritt 1006 fort, ansonsten fährt die Funktion mit Schritt 1908 fort. In Schritt 1908 ruft die Methode die GetUser Methode des Verweisobjektes, auf das durch den Zeiger für das letzte Element gezeigt wird, auf, um den Dateinamen des letzten Elements mit der Präfix zu erhalten. In Schritt 1909 untersucht sie die Objekttabelle an einer bekannten Stelle in dem Dateinamen, den sie erhalten hat, um den Eintrag zu finden, der dem aktuellen Verweisobjekt entspricht. Die Elemente in der Tabelle haben die Form eines Dreituppel (WItemMoniker, IStorage, UserName). Von dieser Tabelle holt die Methode den Speicherungszeiger und den Benutzernamen für das neue Verweisobjekt, daß es erzeugen wird. Als nächstes, in Schritt 1910 hängt sie den Benutzernamen des Dateinamens des letzten Elements der Präfix an den neuen Namen, den sie erhalten hat. In Schritt 1911 erzeugt die Methode ein neues IStorage Verweisobjekt mit dem Speicherungszeiger und dem neuen Namen. In Schritt 1912 wird die Präfix auf den Rest dessen gesetzt, was die Präfix minus dem letzten Element war. Als letztes, in Schritt 1913, wird der Ausgabeparameter auf das neue erzeugte IStorage Verweisobjekt gesetzt, und die Funktion kehrt zurück.
Fig. 20 zeigt ein übergeordnetes Ablaufdiagramm für die Funktion MkParseUserName. Diese Funktion nimmt einen Namen einer Zeichenkette und gibt ihr entsprechendes Verweisobjekt zurück. Das zurückgegebene Verweisobjekt kann ein zusammengesetztes Verweisobjekt sein. In Schrift 2001 zerlegt (parse) die Funktion die Zeichenkette, um einen gültigen Dateinamen zu finden. In Schritt 2002 erzeugt die Funktion ein Dateiverweisobjekt für diesen Dateinamen und speichert ihn in der Variable pfm. In Schritt 2003 setzt die Funktion die übergebliebene Zeichenkette auf die anfänglich übergebene Zeichenkette ohne die verbrauchten Zeichen. Als letztes, in Schritt 2004, ruft die Funktion die ParseUserName Methode für das Dateiverweisobjekt, auf das durch pfm gezeigt wird, auf und gibt es der übergebliebenen Zeichenkette und der Adresse des Rückkehrverweisobjektes. Sobald die Methode des Dateiverweisobjektes ParseUserName zurückgekehrt ist, wird der Rest der Zeichenkette zerlegt sein. Die Funktion kehrt dann zurück.
Fig. 21 zeigt ein übergeordnetes Ablaufdiagramm für die Methode ParseUserName für eine typische Implementierung eines Dateiverweisobjektes. Weil es die Arten der Objekte, die es enthalten kann, nicht kennt, muß die Methode entscheiden, ob es mit dem Objekt, welches durch den Dateinamen angezeigt wird, binden muß, um den nächsten Teil der Zeichenkette zu zerlegen. Diese Methode nimmt vier Parameter: einen Zeiger auf einen Bindkontext, den Zeiger auf das Präfixverweisobjekt, den restlichen Namen der Zeichenkette, die zerlegt werden soll und einen Zeiger auf das resultierende Verweisobjekt. In Schritt 2101 entscheidet die Methode, ob es den Syntax der Objekte, die in dieser Datei enthalten sind, verstehen kann. Wenn sie den Syntax verstehen kann, fährt die Methode mit Schritt 2102 fort, ansonsten fährt sie mit Schritt 2103 fort. In Schritt 2102 ruft die Methode ihre interne Routine zum Zerlegen einer Zeichenkette (internal parse string routine) auf und erzeugt ein Verweisobjekt für den Teil der Zeichenkette, den sie zerlegen konnte. Sie fährt dann mit Schritt 2105 fort. In 2103 ruft die Methode BindToObject auf sich selbst auf, übergibt ihr die Präfix, die an die ParseUserName Methode überreicht wurde. Als nächstes, in Schritt 2104, ruft diese Methode die ParseUserName Methode des Objektes, das gebunden wurde, um ihr die Präfix zu übergeben, und die restliche Benutzerzeichenkette, die noch zerlegt werden muß. Als letztes, in Schritt 2105, wird die ComposeWith Methode der Präfix aufgerufen, um das neu erzeugte Verweisobjekt zu addieren. Die Funktion kehrt zurück.

Claims

1. Verfahren in einem Computersystem zum Binden eines Objekts in einem ersten zusammengesetzten Dokument an Daten, die sich in einem zweiten Dokument befinden, das Verfahren umfassend die Schritte:

Instanzieren eines Verweisobjekts, wobei das Verweisobjekt zum Speichern von Informationen, die die Daten in dem zweiten Dokument spezifizieren, und zum Bereitstellen einer Funktion zum Binden an die Daten in dem zweiten Dokument ist,

Speichern des Verweisobjekts in dem ersten Dokument, und Aufrufen der Bindefunktion des gespeicherten Verweisobjekts, um an die Daten in dem zweiten Dokument anzubinden.

2. Verfahren nach Anspruch 1, wobei das Speichern des Verweisobjekts eine Referenz auf das Verweisobjekt speichert.

3. Verfahren nach Anspruch 1, wobei die Funktion ein Quellobjekt für die Daten instanziert und einen Zeiger auf das instanzierte Quellobjekt zurückgibt.

4. Verfahren nach Anspruch 1, wobei das instanzierte Verweisobjekt ein zusammengesetztes Verweisobjekt ist.

5. Verfahren nach Anspruch 4, umfassend Speichern einer Referenz auf ein erstes Komponentenverweisobjekt und einer Referenz auf ein zweites Komponentenverweisobjekt in dem zusammengesetzten Verweisobjekt, wobei das zweite Komponentenverweisobjekt mit dem ersten Komponentenverweisobjekt zusammengestellt ist, um auf einen Posten in den Daten zu verweisen.

6. Verfahren nach Anspruch 5, wobei die Bindefunktion die Bindefunktion des ersten Komponentenverweisobjekts aufruft und die Bindefunktion des ersten Verweisobjekts die Bindefunktion des zweiten Komponentenverweisobjekts aufruft.

7. Verfahren nach Anspruch 1, wobei das Speichern des Verweisobjekts Speichern eines Bezeichners einer Klasse des Verweisobjekts zusammen mit Informationen zum Auffinden der Daten, die sich in dem zweiten zusammengesetzten Dokument befinden, umfaßt.

8. Verfahren nach Anspruch 1, wobei das Speichern des Verweisobjekts Speichern eines Dateinamens des zweiten Dokuments umfaßt.

9. Verfahren nach Anspruch 1, wobei das Speichern des Verweisobjekts Speichern eines Dateinamens des zweiten Dokuments zusammen mit einem Hinweis auf einen Teil des zweiten Dokuments umfaßt.

10. Verfahren nach Anspruch 1, wobei die Bindefunktion einen Server startet, um Zugriff auf die Daten bereitzustellen.

11. Verfahren nach Anspruch 1, wobei das Verweisobjekt eine Funktion zum Bestimmen anderer Schnittstellen bereitstellt, die durch das Verweisobjekt unterstützt werden.

12. Verfahren nach Anspruch 1, wobei das Verweisobjekt eine Funktion zum Zusammenstellen des Verweisobjekts mit einem anderen Verweisobjekt bereitstellt, um ein zusammengesetztes Verweisobjekt zu bilden.

13. Verfahren nach Anspruch 1, wobei das Verweisobjekt auf die Daten zugreift, ohne einen Server zum Verarbeiten der Daten zu starten.

14. Verfahren nach. Anspruch 1, wobei das Instanzieren des Verweisobjekts Analysieren eines Zeichenkettennamens für die Daten umfaßt.

15. Computersystem zum Binden eines Objekts in einem ersten zusammengesetzten Dokument an Daten, die sich in einem zweiten Dokument befinden, umfassend:

eine Komponente zum Erzeugen einer Instanz eines Verweisobjekts, wobei das Verweisobjekt zum Speichern von Informationen, die die Daten in dem zweiten Dokument spezifizieren, und zum Bereitstellen einer Funktion zum Binden an die Daten in dem zweiten Dokument ist,

eine Komponente zum Speichern einer Referenz zu dem Verweisobjekt in dem erste Dokument, und

eine Komponente zum Aufrufen der Bindefunktion des gespeicherten Verweisobjekts, um an die Daten in dem zweiten Dokument anzubinden.

16. Computersystem nach Anspruch 15, wobei das Speichern des Verweisobjekts eine Referenz auf das Verweisobjekt speichert.

17. Computersystem nach Anspruch 15, wobei die Funktion ein Quellobjekt für die Daten instanziert und einen Zeiger auf das instanzierte Quellobjekt zurückgibt.

18. Computersystem nach Anspruch 15, wobei das instanzierte Verweisobjekt ein zusammengesetztes Verweisobjekt ist.

19. Computersystem nach Anspruch 18, umfassend eine Komponente zum Speichern einer Referenz auf ein erstes Komponentenverweisobjekt und einer Referenz auf ein zweites Komponentenverweisobjekt in dem zusammengesetzten Verweisobjekt, wobei das zweite Komponentenverweisobjekt mit dem ersten Komponentenverweisobjekt zusammengestellt ist, um auf einen Posten in den Daten zu verweisen.

20. Computersystem nach Anspruch 19, wobei die Bindefunktion die Bindefunktion des ersten Komponentenverweisobjekts aufruft und die Bindefunktion des ersten Verweisobjekts die Bindefunktion des zweiten Komponentenverweisobjekts aufruft.

21 Computersystem nach Anspruch 15, wobei das Speichern des Verweisobjekts Speichern eines Bezeichners einer Klasse des Verweisobjekts zusammen mit Informationen zum Auffinden der Daten, die sich in dem zweiten zusammengesetzten Dokument befinden, umfaßt.

22. Computersystem nach Anspruch 15, wobei das Speichern des Verweisobjekts Speichern eines Dateinamens des zweiten Dokuments umfaßt.

23. Computersystem nach Anspruch 15, wobei das Speichern des Verweisobjekts Speichern eines Dateinamens des zweiten Dokuments zusammen mit einem Hinweis auf einen Teil des zweiten Dokuments umfaßt.

24. Computersystem nach Anspruch 15, wobei die Bindefunktion einen Server startet, um Zugriff auf die Daten bereitzustellen.

25. Computersystem nach Anspruch 15, wobei das Verweisobjekt eine Funktion zum Bestimmen anderer Schnittstellen bereitstellt, die durch das Verweisobjekt unterstützt werden.

26. Computersystem nach Anspruch 15, wobei das Verweisobjekt eine Funktion zum Zusammenstellen des Verweisobjekts mit einem anderen Verweisobjekt bereitstellt, um ein zusammengesetztes Verweisobjekt zu bilden.

27. Computersystem nach Anspruch 15, wobei das Verweisobjekt auf die Daten zugreift, ohne einen Server zum Verarbeiten der Daten zu starten.

28. Computersystem nach Anspruch 15, wobei das Instanzieren des Verweisobjekts Analysieren eines Zeichenkettennamens für die Daten umfaßt.