DE69627061T2

DE69627061T2 - OLE zum Entwurf und zur Modellierung

Info

Publication number: DE69627061T2
Application number: DE69627061T
Authority: DE
Inventors: Mark Fayetteville Fortenbery; Cameron M. Decatur Stubbs; Dominique J. Madison Payannet; Robert Huntsville Patience
Original assignee: Intergraph Corp
Current assignee: Intergraph Corp
Priority date: 1995-01-23
Filing date: 1996-01-19
Publication date: 2004-02-12
Anticipated expiration: 2016-01-20
Also published as: US5682468A; EP0723250A3; US5910804A; US6198487B1; EP0723250B1; EP0723250A2; DE69627061D1

Description

Die vorliegende Erfindung bezieht sich auf Verfahren zum Aufrufen von Software-Objekten in einem Computersystem, das einen computerlesbaren Speicher besitzt, unter Verwendung der Verknüpfung und Einbettung von Objekten gemäß den Ansprüchen 1 und 9 und somit allgemein auf das Gebiet der Software für die computergestützte Konstruktion und computergestützte Herstellung (CAD/CAM-Software) und insbesondere auf Verfahren, die die Übertragung von dreidimensionalen Daten zwischen CAD/CAM-Software-Anwendungen ermöglichen.
Überblick über die Verknüpfung und Einbettung von Objekten (OLE) Ein Verfahren, das entwickelt worden ist, um in der Büroumgebung das "Ausschneiden" und "Einfügen" von Daten zwischen Software-Anwendungen zu ermöglichen ist, die "Verknüpfung und Einbettung von Objekten (OLE)". Die OLE definiert genormte Schnittstellen und Funktionen, die ermöglichen, daß Anwender "Objekte" zwischen Software-Anwendungen übertragen. Der folgende Abschnitt ist eine abgekürzte Übersicht über einige der Konzepte, die in der OLE, Version 2.0, von der Microsoft Corporation aus Belleview, Washington, verwendet werden und definiert einige der Begriffe, die in der Offenbarung verwendet werden. Weitere Informationen und Einzelheiten über die OLE können aus "Inside OLE 2" von Kraig Brockschmidt, 1994, Microsoft Press, erhalten werden, aus dem ein Verfahren zum Aufrufen von Software-Objekten in einem Computersystem, das einen computerlesbaren Speicher besitzt, unter Verwendung der Verknüpfung und Einbettung von Objekten bekannt ist, wobei das Verfahren umfaßt:

(a) Erzeugen einer Datenstruktur in einem ersten Software-Anwendungsprogramm, wobei die Datenstruktur Daten speichert, die ein Objekt beschreiben, wobei die Daten zweidimensionale Daten für das Objekt und eine Implementierung eines zweidimensionalen Verfahrens, das als Parameter dem Objekt entsprechende zweidimensionale Daten verwendet, enthalten,
(b) Speichern der Datenstruktur im computerlesbaren Speicher (66, 67); und
(c) Wiedergewinnen der Datenstruktur aus dem computerlesbaren Speicher in einem zweiten Software-Anwendungsprogramm.

Ein Beispiel für das Ausschneiden und Einfügen von Daten zwischen Software-Anwendungen ist in 1 gezeigt. 1 zeigt ein zweidimensionales Objekt 1, das in einer ersten Software-Anwendung erzeugt worden ist und das in eine zweite Software-Anwendung übertragen wird. Die (nicht gezeigte) erste und zweite Software-Anwendung sind üblicherweise Spezial-Software-Anwendungen wie etwa Tabellenkalkulationen, Textverarbeitungsprogramme oder Graphikprogramme. Wenn das zweidimensionale Objekt 1 übertragen worden ist, kann die zweite Software-Anwendung ihre eigenen Daten, das zweidimensionale Objekt 2, manipulieren, so daß das zweidimensionale Objekt 2 mit dem zweidimensionalen Objekt 1 in Wechselwirkung tritt. Das sich ergebende Dokument wird daraufhin an den Anwender ausgegeben.
Die OLE schafft eine Menge von "Schnittstellen" oder Gruppen von Funktionen, die, wenn sie kombiniert werden, die Mechanik schaffen, die ermöglicht, daß der Anwender Daten zwischen Programmen überträgt. 2 zeigt die Übereinkunft zur Darstellung einer OLE-Schnittstelle 10 für ein Objekt 11 und für einen "Verbraucher" 12 des Objekts. Es wird gesagt, daß das Objekt 11 eine "Schnittstellenimplementierung" besitzt, die die Schnittstellen 13 und 14 umfaßt, die analog zu einer "Klasse" der objektorientierten Programmierung sind. Die Schnittstellen 13 und 14 enthalten die Elementfunktionen 15 beziehungsweise 16, die analog zu den "Instanzen" der Klassen der objektorientierten Programmierung sind.
Der Verbraucher 12 empfängt Daten vom Objekt 11 dadurch, daß er Funktionen der Schnittstelle 13 und/oder der Schnittstelle 14 aufruft. In einigen Fällen kann dem Verbraucher lediglich eine der mehreren in einem Objekt verfügbaren Schnittstellen bekannt sein. Das Objekt 10 kann in Reaktion auf die Funktionsaufrufe spezifische Daten über sich selbst an den Verbraucher 12 zurückgeben. Allerdings erhält das Objekt 10 die ausschließliche Steuerung seiner eigenen Daten 17 aufrecht. Wie in 2 weiter gezeigt ist, ist IUnknown eine für das gesamte Objekt verfügbare Schnittstelle, die, wenn sie auf spezifische Schnittstellen abgefragt wird, Zeiger auf die angeforderte Schnittstelle zurückgibt. Beispielsweise kann der Verbraucher 12 unter der Annahme, daß er weiß, welche Funktionen in der Schnittstelle 13 verfügbar sind, einen Zeiger auf die Schnittstelle 14 anfordern und empfangen. Wenn der Verbraucher 12 daraufhin einen Zeiger auf die Schnittstelle 14 empfängt, kann er die Elementfunktionen 16 aufrufen.
Die in der momentan verfügbaren OLE bereitgestellten Funktionen normen die Übertragung der Anordnungs- und Größeninformationen von Objekten zwischen Software-Anwendungen. Zwei Arten der "Übertragung" von Objekten von einer ersten Software-Anwendung zu einer zweiten Software-Anwendung umfassen die "Verknüpfung" und die "Einbettung".
Die "Verknüpfung" eines Objekts, das in einer ersten Software-Anwendung erzeugt worden ist, mit einer zweiten Software-Anwendung erfolgt, wenn das Objekt seine Existenz getrennt von der zweiten Software-Anwendung aufrechterhält, obgleich die zweite Software-Anwendung das Objekt "nutzen" und auf es Bezug nehmen kann. Außerdem ermöglicht die Verknüpfung, daß der Anwender das Objekt mit der ersten Software-Anwendung modifiziert und editiert, ohne daß er die zweite Software-Anwendung aufrufen muß.
Die "Einbettung" eines ersten Datenobjekts in eine zweite Software-Anwendung erfolgt, wenn das Objekt tatsächlich mit den von der zweiten Software-Anwendung gespeicherten und verwendeten Daten integriert wird. Die Einbettung ermöglicht, daß der Anwender das Objekt erst nach dem ersten Aufruf der zweiten Software-Anwendung modifiziert und editiert.
Die "Verknüpfung" eines Objekts wird üblicherweise bevorzugt, wenn das verknüpfte Objekt eine große Menge an Daten enthält. Ein Nachteil der Verknüpfung umfaßt aber das Unterhalten des besonderen Pfads oder Verzeichnisses des verknüpften Objekts in dem Computerspeicher und das Erinnern an ihn. Die "Einbettung" eines Objekts wird üblicherweise bevorzugt, wenn es wichtig ist, die Positionierung und Beziehung des eingebetteten Objekts zu anderen Daten in der zweiten Software-Anwendung zu unterhalten. Ein Nachteil der Einbettung umfaßt aber, daß das eingebettete Objekt durch den Anwender nicht editiert oder modifiziert werden kann, ohne die zweite Software-Anwendung aufzurufen.
Zwei weitere üblicherweise verwendete OLE-Begriffe sind "Server" und "Container". Wie in 2 gezeigt ist, sind die Daten 17 tatsächlich nur ein Teil des Objekts 10. Die Funktionen 15 und 16 dienen dazu, die Daten 17 zu manipulieren und diese Daten zu dem Verbraucher 12 zu transportieren. Da das Objekt 10 die Daten "bedient" und ihr Management ausführt, wird es häufig "Server" genannt. Ein "Container" ist als der Anwender der in dem Server enthaltenen Informationen definiert. In 2 ist der Container der Verbraucher 12. In einem makroskopischen Maßstab ist der Server in dem Beispiel in 1 die erste Software-Anwendung, die das Management des Objekts 1 ausführt, während der Container die zweite Software-Anwendung ist. Ein Container kann auf mehrere Server, auf einen für jedes Objekt in der "Umgebung" des Containers, zugreifen, wobei Container und Server ferner verschachtelt sein können.
Der Begriff "In-Place-Aktivierung" ist ein weiterer wichtiger Begriff in der OLE. Die "In-Place"-Aktivierung ermöglicht, daß eine erste Software-Anwendung in einer zweiten Software-Anwendung aktiv ist. Wie in 1 gezeigt ist, wird ein Objekt 1, das in einer Tabellenkalkulationsanwendung erzeugt wurde, in ein Dokument 2 eingesetzt, das durch eine Textverarbeitungsanwendung erzeugt wurde. Ohne die In-Place-Aktivierungsfähigkeit müßte der Anwender normalerweise, wenn er die Einträge im Objekt 1 überarbeiten möchte, nachdem das Objekt 1 in das Dokument 2 eingesetzt worden ist, die Textverarbeitungsanwendung abschließen, in die Tabellenkalkulationsanwendung eintreten, das Objekt 1 überarbeiten, das Textverarbeitungsprogramm erneut aufrufen und das überarbeitete Objekt 1 daraufhin übertragen. Diese indirekte Art und Weise des Editierens eines übertragenen Objekts findet statt, da die Software-Anwendung, die das Objekt empfängt, das Objekt lediglich als zweidimensionale Blackbox erkennt. Mit der In-Place-Aktivierung kann der Anwender die Tabellenkalkulationsanwendung aus der Textverarbeitungsanwendung heraus direkt aufrufen. Die OLE stellt die Schnittstellenfähigkeit für die zwei Software-Anwendungen bereit, so daß sie miteinander kommunizieren können. Im Ergebnis kann der Anwender das Objekt 1 unter Verwendung der Tabellenkalkulationsanwendung überarbeiten, ohne die Textverarbeitungsanwendung zu verlassen.
Die OLE-Version 2.0 ist momentan verfügbar bei dem Betriebssystem Windows^TM, Version 3.1, der Microsoft Corporation. Momentan unterstützen viele Büroumgebungs-Software-Anwendungen wie etwa Excel und Word von der Microsoft Corporation die OLE-Standards und -Schnittstellen. Wie in 1 gezeigt wurde, wird das in der ersten Software-Anwendung wie etwa in einer Tabellenkalkulation erzeugte Objekt 1 in eine zweite Software-Anwendung wie etwa in eine Textverarbeitung übertragen. Unter anderen zwischen den Software-Anwendungen übergebenen Variablen muß die zweite Software-Anwendung die zweidimensionale Größe des Objekts 1 kennen, so daß sie für es in dem Dokument Platz schaffen kann. Die zweite Software-Anwendung erhält die zweidimensionale Größe des ersten Datenobjekts 1 dadurch, daß sie OLE-Funktionen aufruft und sich auf sie stützt. Auf der Grundlage der zweidimensionalen Größe kann die zweite Software-Anwendung ihre eigenen Daten, das Objekt 2, modifizieren, so daß es das Objekt 1 "umläuft".
Die OLE ist nicht auf zweidimensionale Objekte beschränkt und wird ebenfalls zum Integrieren und Übertragen von Audio- und Videodaten zwischen Software-Anwendungen verwendet. Die momentanen OLE-Funktionen arbeiten gut mit Büroumgebungs-Datenobjekten, d. h. zweidimensionalen Objekten, die durch zweidimensionale graphische Begrenzungslinien definiert sind. Allerdings ermöglichen die OLE-Funktionen lediglich, daß der Anwender an den Boxen rudimentäre zweidimensionale Funktionen wie etwa Skalieren, Lokalisieren und Drehen ausführt.
Übersicht über den CAD/CAM-Markt
Anwendungs-Software, die spezifisch für Architektur- und Ingenieurzwecke entworfen wurde, wird üblicherweise als Software für die computergestützte Konstruktion (CAD) und computergestützte Herstellung (CAM) bezeichnet. Einige der Standardmerkmale von CAD/CAM-Anwendungen sind die Fähigkeit zum Erzeugen und Manipulieren dreidimensionaler Objekte und zum Positionieren dreidimensionaler Objekte in bezug auf andere dreidimensionale Objekte.
Wie in 3 gezeigt ist, wird ein dreidimensionales Objekt dem Anwender in einer CAD/CAM-Umgebung in Form eines Ausdrucks oder einer Anzeige typischerweise als zweidimensionales Bild dargestellt. Beispiele üblicherweise angezeigter Ansichten eines dreidimensionalen Objekts sind eine Draufsicht, eine rechte Seitenansicht, eine Vorderansicht und eine isometrische Darstellung. 3 zeigt, daß eine Draufsicht, eine rechte Seitenansicht und eine Vorderansicht des dreidimensionalen Objekts 20 von orthogonalen Projektionen auf eine obere zweidimensionale Ansichtsebene 21, auf eine rechte zweidimensionale Ansichtsebene 22 beziehungsweise auf eine vordere zweidimensionale Ansichtsebene 23 abgeleitet sind. Außerdem zeigt 3, daß eine isometrische Darstellung des dreidimensionalen Objekts 20 aus Projektionen auf eine isometrische Ansichtsebene 24 abgeleitet ist.
In der Vergangenheit waren CAD/CAM-Software-Anwendungen wegen der hohen Computer- und Anzeigeanforderungen der Software eng an Spezial-Computer-Hardware gekoppelt. Wegen dieser Spezialisierung waren diese CAD/CAM-Workstations vollständige, selbständige Arbeitsumgebungen. Wenn der Anwender Workstations eines Herstellers nutzte, gab es wegen Kostenerwägungen wenig Möglichkeit, Workstations eines anderen Herstellers zu verwenden. Da der Anwender in der Vergangenheit dazu neigte, bei einem besonderen Hersteller zu bleiben, gab es wenig Notwendigkeit, dreidimensionale Objekte, die in einer ersten CAD/CAM-Anwendung erzeugt wurden, in eine zweite CAD/CAM-Anwendung zu übertragen.
Mit der Zunahme der Verarbeitungsfähigkeiten von Personal Computern ersetzen Personal Computer nun die herkömmlichen Workstations des Entwicklers. Diese Verschiebung in der CAD/CAM-Rechnerumgebung hat die Bindungen des Anwenders an einen besonderen Hersteller verringert und ermöglicht nun, daß der Anwender diejenige CAD/CAM-Anwendung wählt, die am besten an das Problem oder an die Prioritäten des Anwenders angepaßt ist. Außerdem können mit der Zunahme der Computerplattformen nun mehr als ein Ingenieur an dem gleichen Problem gleichzeitig arbeiten.
Momentan stützen sich CAD/CAM-Pakete von verschiedenen Herstellern auf herstellerspezifische Datenformate, wobei sie nicht ermöglichen, daß der Anwender Objekte, die in einer Software-Anwendung erzeugt wurden, in eine Software-Anwendung eines anderen Herstellers überträgt. Somit ist die CAD/CAM-Software nicht fortgeschrittener geworden, während die Computer-Hardware fortgeschrittener geworden ist. Was benötigt wird, sind Software-Funktionen und -Hilfsmittel, die ermöglichen, daß der Anwender Datenobjekte, die durch eine erste CAD/CAM-Software-Anwendung erzeugt wurden, in eine zweite CAD/CAM-Software-Anwendung überträgt.
Wenn der Anwender momentan versucht, die vorhanden zweidimensionalen Funktionen der OLE zu verwenden und sie im Gebiet der CAD/CAM-Anwendungen anzuwenden, wird die Form eines dreidimensionalen Objekts nicht übertragen. 4 zeigt eine Vorderansicht 30 eines ersten dreidimensionalen Objekts, das durch eine erste Software-Anwendung erzeugt wurde, und eine isometrische Darstellung 31 eines zweiten dreidimensionalen Objekts, das durch eine zweite Software-Anwendung erzeugt wurde. In Übereinstimmung mit dem OLE-Standard ist die Vorderansicht 30 durch graphische Begrenzungslinien 32 mit den Abmessungen 33 und 34 definiert. Wenn die Vorderansicht 30 in eine zweite Software-Anwendung übertragen wird, sieht die zweite Software-Anwendung lediglich die zweidimensionalen graphischen Begrenzungslinien 32, während sie keine Kenntnis dessen hat, wie die zwei Objekte in den dreidimensionalen Raum zu integrieren sind. Da Büroumgebungskonzepte von Datenobjekten lediglich zweidimensionale Objekte sind, die durch zweidimensionale graphische Begrenzungslinien definiert sind, ist die OLE zur Verwendung im Gebiet der CAD/CAM-Anwendungen ungeeignet. Ferner stellt die OLE keinen Mechanismus zum Übertragen von Tie feninformationen eines Objekts bereit, selbst wenn es irgendwie möglich wäre, die zweidimensionale Form eines ersten dreidimensionalen Objekts in eine zweite Software-Anwendung zu übertragen.
Was benötigt wird, ist ein genormtes Verfahren, das es dem Anwender ermöglicht, dreidimensionale Daten zwischen Software-Anwendungen zu übertragen.
Die vorliegenden Erfindung schafft Verbesserungen und Ausdehnungen zu der OLE für die CAD/CAM-Umgebung, die ermöglicht, daß der Anwender ein Objekt, das durch eine erste Software-Anwendung erzeugt wurde, in eine zweite Software-Anwendung überträgt, während das dreidimensionale Wesen des Objekts erhalten bleibt.
1 zeigt ein in einer ersten Software-Anwendung erzeugtes zweidimensionales Objekt 1, das in eine zweite Software-Anwendung übertragen wird;
2 zeigt die Übereinkunft zur Darstellung einer OLE-Schnittstelle für ein Objekt und für einen "Verbraucher" des Objekts;
3 zeigt, daß eine Draufsicht, eine rechte Seitenansicht und eine Vorderansicht eines dreidimensionalen Objekts von orthogonalen Projektionen auf eine obere zweidimensionale Ansichtsebene, auf eine rechte zweidimensionale Ansichtsebene beziehungsweise auf eine vordere zweidimensionale Ansichtsebene abgeleitet sind;
4 zeigt eine Vorderansicht eines durch eine erste Software-Anwendung erzeugten ersten dreidimensionalen Objekts und eine isometrische Ansicht eines durch eine zweite Software-Anwendung erzeugten zweiten dreidimensionalen Objekts;
5 zeigt, daß ein erstes dreidimensionales Objekt mit einer ersten Software-Anwendung erzeugt wird, während ein zweites dreidimensionales Objekt in einer zweiten Software-Anwendung erzeugt wird;
6 zeigt das Konzept der Transparenz bei einer Anzeige eines dreidimensionalen Objekts und eines zweidimensionalen Objekts in einem dreidimensionalen Koordinatensystem;
7 ist ein Blockschaltplan eines Systems gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
8 zeigt die IOIe3DObject-Schnittstelle in einer Anwenderschnittstelle eines Objekts;
9 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestim mung, ob das Objekt ein dreidimensionales Objekt ist;
10a und 10b zeigen zwei verschiedene Orientierungen eines Objekts in bezug auf sein eigenes Koordinatensystem und in bezug auf das Koordinatensystem eines Containers;
11a und 11b sind Ablaufpläne einer Ausführungsform des Prozesses der Bestimmung der tatsächlichen Ausdehnung eines dreidimensionalen Objekts in einem Container unter Verwendung von IOIe3DObject::Get3DExtent;
12 zeigt, daß ein dreidimensionales Objekt 310 und ein zweidimensionales Objekt in einen dreidimensionalen Container eingesetzt sind;
13 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob ein zweidimensionaler Container eine Ansicht eines dreidimensionalen Objekts wiedergewinnen kann;
14 zeigt einen Ablaufplan einer Ausführungsform des Prozesses, in dem ein zweidimensionaler Container GetDefaultView aufruft, um eine Standardansicht eines dreidimensionalen Objekts anzuzeigen;
15 zeigt eine Standardansicht (die Vorderansicht) eines dreidimensionalen Objekts, das in einen zweidimensionalen Container eingesetzt ist;
16 zeigt einen Ablaufplan einer Ausführungsform des Prozesses des Aufrufs von SetView, was ermöglicht, daß ein zweidimensionaler Container eine Ansicht eines dreidimensionalen Objekts einstellt und anzeigt;
17 zeigt eine Ansicht eines dreidimensionalen Objekts, das in einen zweidimensionalen Container eingesetzt ist;
18 zeigt die IViewGLObject-Schnittstelle für eine Anwenderschnittstelle eines Objekts;
19 ist ein Ablaufplan einer Ausführungsform des Prozesses zur Bestimmung, ob das Objekt OpenGL COM unterstützt;
20 ist ein Ablaufplan einer Ausführungsform des Prozesses, in dem veranlaßt wird, daß ein Server das Objekt durch Aufruf von OpenGL-COM-Funktionen anzeigt;
21 zeigt die IOIeInPlace3DObject-Schnittstelle für eine Anwenderschnittstelle eines Objekts;
22 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das dreidimensionale Objekt die In-Place-Aktivierung unterstützt;
23 zeigt, daß die Befestigungsmatrix zwischen dem Server-Koordinatensystem und dem Container-Koordinatensystem anfangs berechnet wird;
24 zeigt eine Draufsicht, eine Vorderansicht und eine rechte Seitenansicht eines dreidimensionalen Objekts;
25 zeigt die IOIeInPlace3DSite-Schnittstelle für eine Anwenderschnittstelle für ein dreidimensionales Objekt;
26 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das dreidimensionale Objekt die In-Place-Aktivierung unterstützt;
27 zeigt ein Objekt, das in einen ersten Container eingebettet ist, der in einen zweiten Container eingebettet ist;
28 zeigt, wie anfangs die Befestigungsmatrix zwischen dem In-Placeaktiven Server-Koordinatensystem und dem Koordinatensystem des unmittelbar angrenzenden Containers berechnet wird;
29 zeigt die IOIeInPlaceViews-Schnittstelle für eine Anwenderschnittstelle für ein dreidimensionales Objekt;
30 zeigt eine IOIeInPlaceActive3DObject-Schnittstelle für eine Anwenderschnittstelle;
31 zeigt die IOIeLocate-Schnittstelle für eine Anwenderschnittstelle eines Objekts;
32 ist ein Ablaufplan einer Ausführungsform des Prozesses des Lokalisierens von Elementen in einem Objekt unter Verwendung der PointLocate-Funktion;
33 ist ein Ablaufplan einer Ausführungsform des Prozesses des Lokalisierens von Elementen in einem Objekt unter Verwendung der ShapeLocate-Funktion;
34a-34c zeigen die Verwendung der IOIeLocate::PointLocate-Funktion; und
35 ist ein Ablaufplan einer Ausführungsform des Prozesses der inplace-Aktivierung.
Eine der Aufgaben der folgenden OLE-Ausdehnungen ist es, zu ermöglichen, daß der Anwender dreidimensionale Objekte zwischen Software-Anwendungen überträgt. Ein Beispiel hiervon ist in 5 gezeigt. In 5 wird ein erstes dreidimensionales Objekt 40 mit einer ersten Software-Anwendung erzeugt, während ein zweites dreidimensionales Objekt 41 in einer zweiten Software-Anwendung erzeugt wird. Das erste dreidimensionale Objekt 40 enthält einen oberen Schenkel 42, einen unteren Schenkel 43 und einen Schlitz 44. Wenn das erste dreidimensionale Objekt 50 in der zweiten Software-Anwendung wiedergewonnen wird, sollte die zweite Software-Anwendung das erste dreidimensionale Objekt wie eines seiner eigenen skalieren, drehen und manipulieren können. (Allerdings kann die zweite Software-Anwendung das Objekt immer noch nicht editieren.) Wie in 5 gezeigt ist, werden das erste dreidimensionale Objekt 40 und das zweite dreidimensionale Objekt 41 beide in dem dreidimensionalen Koordinatensystem der zweiten Software-Anwendung gedreht und zusammengesetzt. Die zweite Software-Anwendung sollte das dreidimensionale Wesen des ersten dreidimensionalen Objekts 40 erkennen können, indem sie ermöglicht, daß der obere Schenkel 42 einen Teil des zweiten dreidimensionalen Objekts 41 verdeckt, und indem sie ermöglicht, daß das zweite dreidimensionale Objekt 41 einen Teil des unteren Schenkels 43 verdeckt.
Ein spezifisches Ergebnis der folgenden OLE-Ausdehnungen ist es, daß sie ermöglichen, daß dreidimensionale Objekte durchsichtige graphische Begrenzungslinien haben. 6 zeigt das Konzept der Durchsichtigkeit bei einer Anzeige 50 eines dreidimensionalen Objekts 51 und eines zweidimensionalen Objekts 52 in einem dreidimensionalen Koordinatensystem. Das dreidimensionale Objekt 51 enthält den Schlitz 54, während das zweidimensionale Objekt 52 die Fläche 54 enthält.
Die momentane OLE ermöglicht, daß der Anwender zweidimensionale "Blackboxes" von Informationen ohne Bezug auf die Inhalte der Box überträgt. Falls ein erstes dreidimensionales Objekt an die zweite Software-Anwendung zurückgegeben wird, sollte die zweite Software-Anwendung die tatsächliche Form des dreidimensionalen Objekts empfangen und, wenn das Bild übertragen wird, nicht mehr von ihm als erforderlich verdecken. Wie in 6 gezeigt ist, erkennt die zweite Software-Anwendung mit den folgenden OLE-Ausdehnungen, daß der Schlitz 53 ermöglicht, daß der Anwender durch das Objekt 51 sieht, d. h., das Objekt 51 ist im Schlitz 53 durchsichtig, so daß das darunterliegende zweidimensionale Objekt 52 in der Fläche 54 sichtbar bleibt.
Zusammengefaßt schafft das Hinzufügen der im folgenden beschriebenen Ausdehnungen zur OLE die folgende Fähigkeit: 1) Ermöglichen der Kommunikation zwischen dreidimensionalen Objekten, Servern und Containern sowie Ermöglichen der Kommunikation zwischen zweidimensionalen Containern und dreidimensionalen Objekten und Servern und Ermöglichen der Kommunikation zwischen dreidimensionalen Containern und zweidimensionalen Objekten; 2) Ermöglichen, daß dreidimensionale Server in einer zwei- oder dreidimensionalen Contai nerumgebung navigieren einschließlich des Ermöglichens mehrerer In-Place-aktiver Ansichten; und 3) Ermöglichen, daß dreidimensionale Objekte mit anderen Objekten in der Container-Umgebung in Wechselwirkung treten.
Es wird angenommen, daß jemand, der mit der OLE vertraut ist, wie sie in "Inside OLE 2" von Kraig Brockschmidt beschrieben ist, die folgenden OLE-Ausdehnungen anhand der folgenden Offenbarung leicht verwenden kann. Weitere Einzelheiten über das bevorzugte Verfahren, das diese Übertragung von Daten ermöglicht, sind in den folgenden Abschnitten offenbart.
Systemübersicht
7 ist ein Blockschaltplan eines Systems 60 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Das System 60 enthält einen Anzeigemonitor 61, einen Computer 62, eine Tastatur 63 und eine Maus 64. Der Computer 62 enthält bekannte Computerkomponenten wie etwa einen Prozessor 65 und Speichervorrichtungen wie etwa einen Schreib-Lese-Speicher (RAM) 66, ein Plattenlaufwerk 67 und einen Systembus 68, der die obigen Komponenten verbindet. Die Maus 64 ist nur ein Beispiel einer graphischen Eingabevorrichtung, während ein Digitalisiertablett 65 ein weiteres Beispiel ist.
In einer bevorzugten Ausführungsform enthält das System 60 einen IBM-PC-kompatiblen Personal Computer, auf dem das Betriebssystem Windows^TM, Version 3.1, und OLE 2.0 von der Microsoft Corporation sowie die Software Ava-lon^TM, die momentan unter Entwicklung durch die Intergraph Corporation ist, laufen. Der Anhang enthält in Visual C++ geschriebene bevorzugte Ausführungsformen der untenbeschriebenen Avalon^TM-OLE-Ausdehnungen. Außerdem enthält der Anhang Beispiel-Quellcodeprogramme, die die Avalon^TM-OLE-Ausdehnungen enthalten.
7 repräsentiert nur einen Typ eines Systems, das die vorliegende Erfindung verkörpert. Für einen Durchschnittsfachmann auf dem Gebiet ist leicht ersichtlich, daß zur Verwendung in Verbindung mit der vorliegenden Erfindung viele Systemtypen und -konfigurationen geeignet sind.
Dreidimensionale Ausdehnungen für die OLE
0. Typdefinitionen
1. Schnittstellen, die die Behandlung dreidimensionaler Objekte ermöglichen
1.1 Iole3DObject-Schnittstelle
1.2 IViewGLObject-Schnittstelle
1.3 IOIeInPlace3DObject-Schnittstelle
2. Schnittstellen, die die Navigation einer Container-Umgebung ermöglichen
2.1 IOIeInPlace3DSite-Schnittstelle
2.2 IOIeInPlaceViews-Schnittstelle
2.3 IOIeInPlaceActive3DObject-Schnittstelle
3. Schnittstellen, die die Wechselwirkung dreidimensionaler Objekte ermöglichen
3.1 IOIeLocate-Schnittstelle
0. Typdefinitionen
Das folgende sind in der bevorzugten Ausführungsform in C++ beschriebene Typdefinitionen, die in den Beschreibungen der bevorzugten Ausführungsform der formalen OLE-Ausdehnungsschnittstellen verwendet werden.
tagDVREP wird verwendet, um anzugeben, wie das Objekt dem Anwender angezeigt wird.
EXTENT3D ist eine Liste von Koordinaten, die den Bereich des Objekts in drei Dimensionen definieren.
Die Abschneideebenengleichungen sind eine Menge von vier Punkten im Raum, die eine Ebene definieren, die ihrerseits eine Grenze im Raum definieren.
XFORM3D ist eine Matrix, die für den Transport von Parametern in das dreidimensionale Rendering-Hilfsmittel verwendet wird.
1. Schnittstellen, die die dreidimensionale Objektbehandlung ermöglichen
Die neuen OLE-Schnittstellen, wie sie hier beschrieben werden, ermöglichen, daß Container und Server, die beide dreidimensionale Objekte manipulieren, die dritte Dimension nutzen, während sie die Abwärtskompatibilität erhalten. Genauer ermöglichen die neuen Schnittstellen, zweidimensionale Objekte in dreidimensionale Container einzusetzen und dreidimensionale Objekte in zweidimensionale Container einzusetzen. Allerdings fügt die Manipulation eines Objekts immer noch nicht die Fähigkeit hinzu, ein übertragenes Objekt zu editieren.
Wenn nichts angegeben ist, bezieht sich der Begriff "Container" im folgenden auf einen Container, der entweder zweidimensionale oder dreidimensionale Objekte unterstützt, während sich der Begriff "Objekt" auf ein dreidimensionales Objekt oder auf zweidimensionales Objekt bezieht.
1.1 IOIe3DObject-Schnittstelle
Die IOIe3DObject-Schnittstelle ist eine Ausdehnung der existierenden OLE-IOIeObject-Schnittstelle und ermöglicht, daß ein dreidimensionaler Container dreidimensionale Informationen über ein Objekt wiedergewinnt. IOIe3DObject-Funktionen werden mit der untenbeschriebenen hinzugefügten Funktionalität im gleichen Programmierkontext wie die IOIeObject-Funktionen verwendet. Außerdem ermöglicht die IOIe3DObject-Schnittstelle einen zweidimensionalen Container, der drei Dimensionen versteht, um eine Ansicht des dreidimensionalen Objekts anzugeben und wiederzugewinnen.
8 zeigt die IOIe3DObject-Schnittstelle 70 in einer Anwenderschnittstelle 72 eines Objekts. Die Anwenderschnittstelle 72 enthält eine IUnknown-Schnittstelle 74, die in allen OLE-Objekten verfügbar ist, und eine IOIeObject-Schnittstelle 76, die ebenfalls in allen OLE-Objekten verfügbar ist. Die IUnknown-Schnittstelle 74 enthält eine Schnittstellenimplementierung mit einer Funktion 78, die, wenn sie aufgerufen wird, einen Zeiger auf die lOIe3dObject-Schnittstelle 70 zurückgibt, falls das Objekt ein dreidimensionales Objekt ist, und eine Funktion 80, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeObject-Schnittstelle 76 zurückgibt. Die IOIeObject-Schnittstelle 76 enthält eine Implementierung mit einer Funktion 82, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIe3dObject-Schnittstelle 70 zurückgibt, wenn das Objekt ein dreidimensionales Objekt ist. Die IOIe3DObject-Schnittstelle 70 enthält eine Implementierung mit den untenbeschriebenen Funktionen 84, 86, 88, 90 und 92.
9 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das Objekt ein dreidimensionales Objekt ist.
Während der Initialisierung eines Objekts (z. B. während des Erzeugens oder Ladens eines Objekts) fragt der Container die IUnknown-Funktion 78 wegen eines Zeigers auf die IOIe3DObject-Schnittstelle 70 ab (Schritt 100). Gleichzeitig fragt der Container die IUnknown-Funktion 80 wegen eines Zeigers auf die IOIe-Object-Schnittstelle 76 ab, falls das Objekt kein dreidimensionales Objekt ist (Schritt 110).
In einer bevorzugten Ausführungsform fragt der Container ferner die IOIe-Object-Funktion 82 wegen eines Zeigers auf die IOIe3DObject-Schnittstelle 70 ab. Wenn die IOIe3DObject-Schnittstelle 70 lokalisiert ist, fragt der Container die IOIe3DObject-Funktion 84 ab, wobei er sicherstellt, daß es einen Zeiger auf die IOIeObject-Schnittstelle 76 gibt.
Falls die Abfrage der IOeObject-Funktion 82 oder der IUnknown-Funktion 78 einen NULL-Zeiger zurückgibt (Schritt 120), ist das Objekt kein dreidimensionales Objekt, wobei der Container das Objekt als zweidimensionales Objekt behandeln muß (Schritt 130). Falls die obigen Abfragen einen Zeiger auf die IOIe3DObject-Schnittstelle 70 zurückgeben, kann der Container das Objekt als ein dreidimensionales Objekt behandeln (Schritt 140).
Falls eine erste Software-Anwendung unter Verwendung der hier beschriebenen OLE-IOIe3DObject-SchnittstellenAusdehnungen ein dreidimensionales Objekt erzeugt, kann eine weite Software-Anwendung daraufhin praktisch gesprochen IOIe3DObject-Funktionen aufrufen, um dreidimensionale Daten über das Objekt zu erhalten.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIe3DObject-Schnittstelle:
1.1.1. IOIe3DObiect::Get3DExtent
Die erste IOIe3DObject-Funktion Get3DExtent gibt als Reaktion darauf, daß sie von einem Container aufgerufen wird, die "Ausdehnungen" (oder die Reichweite) eines Objekts in drei Dimensionen zurück. Abgesehen davon, daß eine dritte Dimension enthalten ist, ist diese Funktion grob analog zu der momentanen OLE-Funktion IOIeObject::GetExtent. Ein Objekt, das die IOIe3DObject-Schnittstelle unterstützt, muß auch die IOeObject-Schnittstelle unterstützen, damit es mit zweidimensionalen Containern abwärtskompatibel ist.
Bevor die Get3DExtent-Funktion aufgerufen wird, muß der Container zunächst eine "Befestigungs"-Matrix berechnen. Eine Befestigungsmatrix ist eine Abbildung zwischen dem System eines dreidimensionalen Objekts auf das System des Containers, wie sie in den 10a und 10b gezeigt ist.
Die 10a und 10b zeigen zwei verschiedene Orientierungen eines Objekts 160 in bezug auf sein eigenes Koordinatensystem 170 und in bezug auf das Koordinatensystem 180 eines Containers. Wie gezeigt ist, kann das Objekt 160 in bezug auf das Koordinatensystem 180 in drei Dimensionen verschoben, gedreht und skaliert werden. Die Größe und die Orientierung des Objekts 160 in bezug auf sein eigenes Koordinatensystem 170 bleibt aber konstant. Der Container verfolgt die Positionierung und die Größe des Objekts 160 in seinem Koordinatensystem 180 dadurch, daß er eine Befestigungsmatrix berechnet und unterhält, die das Koordinatensystem 170 auf das Koordinatensystem 180 abbildet.
Die 11 a und 11 b sind Ablaufpläne einer Ausführungsform des Prozesses der Bestimmung der tatsächlichen Ausdehnung eines dreidimensionalen Objekts in einem Container unter Verwendung von IOIe3DObject::Get3DExtent.
Damit ein Container die tatsächliche Größe eines Objekts in dem Container-Koordinatensystem berechnet, wird zunächst in 11a eine Befestigungsmatrix berechnet (Schritt 200).
Wenn die Befestigungsmatrix berechnet worden ist, ruft der Container IOIe3DObject::Get3DExtent auf (Schritt 210). Obgleich ein Container, wie eben in den 10a und 10b beschrieben wurde, die Ansicht des Objekts in dem Container-Koordinatensystem manipuliert, erhält das Objekt seine Beziehung zu seinem eigenen Koordinatensystem. Der Server gibt in Reaktion auf den Funktionsaufruf Get3DExtent die Ausdehnung oder die Reichweite des Objekts in bezug auf sein eigenes Koordinatensystem zurück.
Wenn die Befestigungsmatrix und die Ausdehnung des Objekts bestimmt worden sind, berechnet der Container in der bevorzugten Ausführungsform dadurch, daß er die Befestigungsmatrix mit den Ausdehnungswerten multipliziert, die Ausdehnung des Objekts in dem Container-Koordinatensystem (Schritt 220).
Wie in 11 b gezeigt ist, können die Ausdehnungen des Objekts in der Situation, in der das Objekt zweidimensional und der Container dreidimensional ist, weiter berechnet werden. In Schritt 240 wird zunächst eine Befestigungsmatrix berechnet.
Wenn die Befestigungsmatrix berechnet worden ist, ruft der Container die Standard-OLE-Funktion IOIeObject::GetExtent auf (Schritt 250). In Reaktion auf diesen Funktionsaufruf gibt der Server die zweidimensionale Ausdehnung des Objekts in bezug auf sein eigenes Koordinatensystem zurück. Nachfolgend berechnet der Container in der bevorzugten Ausführungsform dadurch, daß er die Befestigungsmatrix mit den Ausdehnungswerten multipliziert, die tatsächliche Ausdehnung des Objekts in dem Container-Koordinatensystem (Schritt 260).
Die Implikationen der Abbildung eines zweidimensionalen Objekts auf einen dreidimensionalen Container sind in 12 gezeigt. In 12 sind ein dreidimensionales Objekt 310 und ein zweidimensionales Objekt 320 in einen dreidimensionalen Container eingesetzt. Das ursprüngliche zweidimensionale Objekt 330 ist ebenfalls gezeigt. Da ein zweidimensionales Objekt auf den dreidimensionalen Raum abgebildet wird, kann das Objekt durch den Container in drei Dimensionen manipuliert werden und mit anderen Objekten wie etwa dem dreidimensionalen Objekt 310 in Wechselwirkung treten.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen Get3DExtent-Schnittstelle:
IOIe3DObject::Get3DExtent
HRESULT IOIe3DObject:: Get3DExtent (DWORD dwRep, LPEXTENTthreedimensional pExtent)
Gibt je nach seiner Darstellung die dreidimensionale Ausdehnung eines dreidimensionalen Objekts zurück.
1.1.2 IOIe3DObject::GetDefauItView
Die nächste IOIe3DObject-Funktion GetDefauItView stellt genauer für einen zweidimensionalen Container die Fähigkeit zum Wiedergewinnen einer im voraus definierten Ansicht eines dreidimensionalen Objekts bereit. Wie in 3 gezeigt wurde, wird ein dreidimensionales Objekt typischerweise als ein zweidimensionales Objekt in einer Betrachtungsebene betrachtet. Weiter wird eine Ansicht wie etwa die Vorderansicht 23 im voraus als Standardansicht definiert.
13 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob ein zweidimensionaler Container eine Ansicht eines dreidimensionalen Objekts wiedergewinnen kann.
Falls ein zweidimensionaler Container dreidimensionale Objekte nicht unterstützt, d. h. keine Kenntnis der IOIe3DObject-Schnittstelle hat, fragt der zweidimensionale Container die IUnknown-Funktion 76 in 7 wegen eines Zeigers auf die IOIeObject-Schnittstelle 76 ab (Schritte 350 und 360). Falls der zweidimensionale Container dreidimensionale Objekte unterstützt, fragt der zweidimensionale Container die IUnknown-Funktion 78 wegen eines Zeigers auf die IOIe3DObject-Schnittstelle 70 ab (Schritte 350 und 370).
Wenn die Abfrage der IUnknown-Funktion 78 einen NULL-Zeiger zurückgibt (Schritt 380), ist das Objekt kein dreidimensionales Objekt, wobei der Container das Objekt als ein herkömmliches zweidimensionales Objekt behandelt. Wenn das Objekt entweder zweidimensional ist oder der Container ein dreidimensionales Objekt nicht unterstützt, gewinnt der Container eine herkömmliche zweidimensionale Ansicht des Objekts wieder (Schritt 4390). Falls die Abfrage in Schritt 380 einen Zeiger auf die IOIe3DObject-Schnittstelle 70 zurückgibt, behandelt der Container das Objekt als ein dreidimensionales Objekt (Schritt 400).
Wenn der Container bestimmt, daß er ein dreidimensionales Objekt unter stützten kann, gewinnt er eine zweidimensionale Ansicht des Objekts wieder.
14 zeigt einen Ablaufplan einer Ausführungsform des Prozesses, in dem ein zweidimensionaler Container GetDefauItView aufruft, um eine Standardansicht eines dreidimensionalen Objekts anzuzeigen.
Bevor die GetDefaultView-Funktion aufgerufen wird, muß der Container zunächst eine "Transformations"-Matrix zwischen dem dreidimensionalen Koordinatensystem des Servers und dem zweidimensionalen Koordinatensystem der Anzeige berechnen. Ein weiterer für diese Matrix verwendeter Begriff ist eine "Serverwelt-Ansichts"-Matrix, bei der die Serverwelt das Koordinatensystem des Objekts und die "Ansicht" das Koordinatensystem der Anzeige ist.
Damit ein Server die Anzeigeposition der Standardansicht des Objekts auf der Anzeige bestimmt, wird in 14 zunächst die "Transformationsmatrix" berechnet (Schritt 420).
Wenn die Transformationsmatrix berechnet worden ist, ruft der Container IOIe3DObject::GetDefauItView auf (Schritt 430) und übergibt die Transformationsmatrix an den Server. Der Server zeigt anhand der Transformationsmatrix auf der Anzeige eine Standardansicht des Objekts an (Schritt 440). Der tatsächliche Prozeß, in dem ein Server das Objekt anzeigt, wird später in dieser Offenbarung diskutiert.
Das Ergebnis dessen, daß ein zweidimensionaler Container eine Standardansicht eines dreidimensionalen Objekts wiedergewinnt und anzeigt, ist in 15 gezeigt. In 15 ist eine Standardansicht 460 (die Vorderansicht) eines dreidimensionalen Objekts 470 in einen zweidimensionalen Container eingesetzt. Nachdem der Container das dreidimensionale Objekt wiedergewonnen und die Transformationsmatrix an den Server übergeben hat, berechnet der Server die Standardansicht 460 für die Anzeige und zeigt sie an. Der tatsächliche Prozeß, in dem ein Server das Objekt anzeigt, wird später in dieser Offenbarung diskutiert. Da der Container, wie gezeigt ist, ebenfalls Kenntnis der Transformationsmatrix und der Positionierung des Objekts hat, kann er daraufhin seine Daten 480 manipulieren, um mit der Standardansicht 460 in Wechselwirkung zu treten.
Die tatsächliche Anzeigeposition des dreidimensionalen Objekts in dem
Container ist durch die Variable IprcPosRect bestimmt, die, wie im obenbeschriebenen "Inside OLE 2" beschrieben ist, durch den Funktionsaufruf OIeInPlace-Site::GetWindowContext zurückgegeben wird.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen GetDefauItView-Schnittstelle:
Gibt die Standardansicht zurück, mit der ein Server anzeigt.

E_INVALIDARG Eines der Argumente ist ungültig.

E_OUTOFMEMORY Nicht genügend Arbeitsspeicher.

E_UNEXPECTED Es ist ein unerwarteter Fehler aufgetreten.
1.1.3 IOIe3DObiect::SetView
Die dritte IOIe3DObject-Funktion stellt genauer für einen zweidimensionalen Container die Fähigkeit bereit, eine Ansicht des dreidimensionalen Objekts anzugeben. Wie in 3 gezeigt ist, muß der dreidimensionale Container von einer Betrachtungsebene aus betrachtet und angezeigt werden. Die vorliegende Funktion ermöglicht, daß ein zweidimensionaler Container diese Betrachtungsebene definiert.
16 zeigt einen Ablaufplan einer Ausführungsform des Prozesses des Aufrufs von SetView, der ermöglicht, daß ein zweidimensionaler Container eine Ansicht eines dreidimensionalen Objekts einstellt und anzeigt.
Damit ein Server die Anzeigeposition der Standardansicht auf einer Anzeige bestimmt, wird in 16 zunächst eine (wie obenbeschriebene) Transformationsmatrix zwischen dem Server-Koordinatensystem und dem Anzeige-Koordinatensystem berechnet (Schritt 490).
Wenn die Transformationsmatrix berechnet worden ist, ruft der Container IOIe3DObject::SetView auf (Schritt 500) und übergibt die Transformationsmatrix an den Server. Anhand der Transformationsmatrix zeigt der Server eine Ansicht des Objekts auf der Anzeige an (Schritt 510). Der tatsächliche Prozeß, in dem ein Server das Objekt anzeigt, wird später in dieser Offenbarung diskutiert.
Das Ergebnis dessen, daß ein zweidimensionaler Container eine Ansicht eines dreidimensionalen Objekts definiert, ist in 17 gezeigt. In 17 ist eine Ansicht 530 eines dreidimensionalen Objekts in einen zweidimensionalen Container eingesetzt. Nachdem der Container das dreidimensionale Objekt wiedergewonnen und die Transformationsmatrix an den Server übergeben hat, berechnet der Server die Ansicht 530 für die Anzeige und zeigt sie an. Da der Container außerdem, wie gezeigt ist, Kenntnis der Transformationsmatrix und der Positionierung des Objekts hat, kann er daraufhin seine Daten 540 manipulieren, um mit der Ansicht 530 in Wechselwirkung zu treten.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen SetView-Schnittstelle:
Ermöglicht, daß der Container die Ansicht angibt, mit der ein Server anzeigt.
1.2. IViewGLObject
Die IViewGLObject-Schnittstelle ist eine Ausdehnung des existierenden OLE-IViewObjects und ermöglicht, daß ein dreidimensionaler Server unter Verwendung von IGL-Schnittstellenroutinen eine Ansicht des Objekts rendert. Die IViewGLObject-Funktionen werden mit der untenbeschriebenen hinzugefügten Funktionalität in dem gleichen Programmierkontext wie die IViewObject-Funktionen verwendet. Die IGL-Schnittstelle OpenGL COM enthält genormte dreidimensionale Graphikrenderfunktionen.
18 zeigt die IViewGLObject-Schnittstelle 550 für eine Anwenderschnittstelle 560 eines Objekts. Die Anwenderschnittstelle 560 umfaßt eine IUnknown-Schnittstelle 570, die in allen OLE-Objekten verfügbar ist, und eine IViewObject-Schnittstelle 580, die ebenfalls in allen OLE-Objekten verfügbar ist. Die IUnknown-Schnittstelle 570 enthält eine Funktion 590, die, wenn sie aufgerufen wird, einen Zeiger auf die IViewGLObject-Schnittstelle 550 zurückgibt, wenn das dreidimensionale Objekt OpenGL-COM-Rendering-Schnittstellen unterstützen kann, und eine Funktion 600, die, wenn sie aufgerufen wird, einen Zeiger auf die IViewObject-Schnittstelle 580 zurückgibt. Die IViewObject-Schnittstelle 580 enthält eine Funktion 610, die, wenn sie aufgerufen wird, einen Zeiger auf die IView-GLObject-Schnittstelle 550 zurückgibt, wenn das dreidimensionale Objekt ein OpenGL-COM-Rendering unterstützen kann, und enthält außerdem eine Standard-OLE-Zeichenfunktion 620. Die IView3DObject-Schnittstelle 550 enthält eine Funktion 630, die, wenn sie aufgerufen wird, einen Zeiger auf die IViewObject-Schnittstelle 580 zurückgibt, und eine Zeichenfunktion 640, wie sie unten beschrieben wird.
19 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das Objekt OpenGL COM unterstützt.
Während der Initialisierung eines Objekts (z. B. während des Erzeugens oder Ladens eines Objekts) fragt der Container die IUnknown-Funktion 590 wegen eines Zeigers auf die IViewGLObject-Schnittstelle 550 ab (Schritt 660). Gleichzeitig fragt der Container die IUnknown-Funktion 600 wegen eines Zeigers auf die IViewObject-Schnittstelle 550 ab, falls das Objekt OpenGL COM nicht unterstützt (Schritt 670).
In einer bevorzugten Ausführungsform fragt der Container ferner die IVie wObject-Funktion 590 wegen eines Zeigers auf die IView3DObject-Schnittstelle 550 ab. Wenn die IView3DObject-Schnittstelle 550 lokalisiert ist, fragt der Container die IView3DObject-Funktion 620 ab, wobei er sicherstellt, daß es einen Zeiger auf die IOIeObject-Schnittstelle 580 gibt.
Falls die Abfrage der IViewObject-Funktion 610 oder der IUnknown-Funktion 590 einen NULL-Zeiger zurückgibt (Schritt 680) unterstützt der Server das OpenGL-COM-Rendering nicht, wobei das Objekt auf die herkömmlich durch die OLE bereitgestellte Weise angezeigt wird (Schritt 690). Falls die obigen Abfragen einen Zeiger auf die IView3DObject-Schnittstelle 550 zurückgeben, unterstützt der Server OpenGL COM (Schritt 700).
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IViewGLObject-Schnittstelle:
1.2.1. IViewGLObiect::Draw
Die Verwendung der IViewGLObject::Draw-Funktion ist verhältnismäßig unkompliziert. 20 ist ein Ablaufplan einer Ausführungsform des Prozesses, in dem veranlaßt wird, daß ein Server das Objekt durch Aufrufen von OpenGL-COM-Funktionen anzeigt.
In 20 wird die Transformationsmatrix zwischen dem Container-Koordinatensystem und der Anzeige (Welt-Ansicht) berechnet (Schritt 720). Nachfolgend werden die Abschneideebenengleichungen definiert, die angeben, welche Teile des Objekts gerendert werden (Schritt 730). Anhand der Transformationsmatrix und der Abfrageebenengleichungen ruft der Server daraufhin IViewGLObject::Draw auf, um das Objekt zu rendern (Schritt 740).
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen Draw-Schnittstelle:
Zeigt einen Server in einem Anzeigekontext an.
Es wird angemerkt, daß sowohl die Ansichts-Welt-, als auch die inverse: Welt-Ansichts-Matrix berechnet wird. Die Welt-Ansicht-Matrix ist wichtig für den Server für ansichtsunabhängige Anzeigen, wenn beispielsweise Text in einem Objekt nicht geschert, gedreht oder schräg angezeigt werden soll.
1.3. IOIeInPlace3DObject
Die IOIeInPlace3DObject-Schnittstelle wird von dreidimensionalen Container-Anwendungen verwendet, um insbesondere während der In-Place-Aktivierung des Servers den dreidimensionalen Anzeigekontext auszuhandeln.
21 zeigt die IOIeInPlace3DObject-Schnittstelle 760 für eine Anwenderschnittstelle 770 eines Objekts. Die Anwenderschnittstelle 770 enthält eine IUnknown-Schnittstelle 780, die in allen OLE-Objekten verfügbar ist, und eine IOIeInPlaceObject-Schnittstelle 790, die in allen OLE-Objekten, die In-Place-aktivieren können, ebenfalls verfügbar ist. Die IUnknown-Schnittstelle 780 enthält eine Funktion 800, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeIn-Place3DObject-Schnittstelle 760 zurückgibt, und eine Funktion 810, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlaceObject-Schnittstelle 790 zurückgibt. Die IOIeInPlaceObject-Schnittstelle 790 enthält eine Funktion 820, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlace3DObject-Schnittstelle 760 zurückgibt. Die IOIeInPlace3DObject-Schnittstelle 760 enthält eine Funktion 830, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlaceObject-Schnittstelle 790 zurückgibt, und außerdem eine OnModelMatrixChange-Funktion 840, wie sie unten beschrieben wird.
22 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das dreidimensionale Objekt die In-Place-Aktivierung unterstützt.
Während der Initialisierung eines Objekts (z. B. während des Erzeugens oder Ladens eines Objekts) fragt der Container die IUnknown-Funktion 800 wegen eines Zeigers auf die IOIeInPIace3DObject-Schnittstelle 760 ab (Schritt 860). Gleichzeitig fragt der Container die IUnknown-Funktion 810 wegen eines Zeigers auf die IOIeInPlaceObject-Schnittstelle 790 ab, falls das Objekt kein dreidimensionales Objekt ist (Schritt 870).
In einer bevorzugten Ausführungsform fragt der Container ferner die IOIeInPlaceObject-Funktion 820 wegen eines Zeigers auf die IOIeIn-Place3DObject-Schnittstelle 760 ab.
Falls die Abfrage der IOIeInPlaceObject-Funktion 820 oder der IUnknown-Funktion 810 einen NULL-Zeiger zurückgibt (Schritt 880), ist das Objekt kein dreidimensionales Objekt, wobei das Objekt unter Verwendung herkömmlicher OLE-Funktionen In-Place-aktiviert wird (Schritt 890). Falls die obigen Abfragen einen Zeiger auf die IOIeInPIace3DObject-Schnittstelle 760 zurückgeben, kann das dreidimensionale Objekt In-Place-aktiviert werden (Schritt 900).
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIeInPIace3DObject-Schnittstelle:
1.3.1 IOIeInplace3DObiect::OnModelMatrixChange
Die OnModelMatrix-Funktion stellt für den In-Place-aktiven Server eine neue Befestigungsmatrix bereit, wenn der Container sein Koordinatensystem modifiziert.
23 ist ein Ablaufplan einer Ausführungsform des Prozesses der Ver- wendung der IOIeInPlace3DObject::OnModelMatrixChange-Funktion. In 23 wird anfangs die Befestigungsmatrix zwischen dem Server-Koordinatensystem und dem Container-Koordinatensystem berechnet (Schritt 920). Wenn das Container-Koordinatensystem modifiziert wird (Schritt 930), berechnet der Container daraufhin eine modifizierte Befestigungsmatrix zwischen dem Server-Koordinatensystem und dem modifizierten Container-Koordinatensystem (Schritt 940). Daraufhin ruft der Container OnModelMatrixChange auf, um den In-Place-Server über die modifizierte Befestigungsmatrix zu benachrichtigen (Schritt 950). Mit der modifizierten Befestigungsmatrix kann der In-Place-Server daraufhin beispielsweise die modifizierte Befestigungsmatrix nehmen und IViewGLObject::Draw aufrufen, um eine aktualisierte Ansicht des Objekts zu zeichnen.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen OnModelMatrixChange-Schnittstelle:
Benachrichtigt das in-place-Objekt, daß der äußerste dreidimensionale Container seine Modell-Transformationsmatrix geändert hat.
Falls Container in anderen Containern verschachtelt sind, wird die Befestigungsmatrix dadurch aufgebaut, daß sämtliche Befestigungsmatrizen von angren zenden Containern und Servern verkettet werden. Somit ist die resultierende Matrix eine Abbildung zwischen dem äußersten dreidimensionalen Container und dem in-place-Server.
2. Schnittstellen, die die Navigation einer Containerumgebung ermöglichen
Die neue OLE-Schnittstelle, wie sie hier beschrieben wird, schafft einen Übergang für dreidimensionale Server und Container, die große Anzahlen von Objekten mit komplizierten Beziehungen enthalten. Besondere Merkmale, die von diesen OLE-Schnittstellen ermöglicht werden, umfassen Objekte mit nicht rechtwinkligen Grenzen und mit durchsichtigen Gebieten. Ein weiteres besonderes Merkmal, das von diesen OLE-Schnittstellen bereitgestellt wird, umfaßt das Ermöglichen, daß ein Container mehrere Ansichten eines Objekts, beispielsweise eine Draufsicht, eine rechte Seitenansicht und eine Vorderansicht eines Objekts, gleichzeitig bereitstellt. Diese neuen OLE-Schnittstellen ermöglichen außerdem, daß Objekte in den verschiedenen Ansichten gleichzeitig In-Place-aktiv werden, wobei das Objekt beispielsweise in einer Ansicht editiert werden kann, während die Ergebnisse automatisch in die anderen Ansichten des Objekts übertragen werden.
24 zeigt eine Draufsicht 970, eine Vorderansicht 980 und eine rechte Seitenansicht 990 eines dreidimensionalen Objekts 1000. Wenn das dreidimensionale Objekt 1000 aktiviert oder wiedergewonnen wird, fordert der Server von dem Container die Positionen, in denen der Container die In-Place-Aktivierung unterstützt, beispielsweise die Positionen 1010, 1020 und 1030, an. In Reaktion auf die Container-Positionen erzeugt der Server eine "Kind"-Ansicht des Objekts, die jeder dieser Positionen entspricht. Jede Ansicht wird einzeln auf ähnliche Weise wie das Standard-OLE-Verfahren des Anzeigens einer Ansicht des Objekts gesteuert. In 24 zeigt der Server an der Position 1010 die Draufsicht 970, an der Position 1020 die Vorderansicht 980 und an der Position 1030 die rechte Seitenansicht 990 an.
Da jede Ansicht gleichzeitig In-Place-aktiv ist, ermöglicht jede Ansicht, daß der Server Ereignisse wie etwa Mausklicks empfängt. Wenn ein Mausklick bei der Standard-OLE außerhalb der In-Place-aktiven Ansicht auftritt, wird die Ansicht deaktiviert, wobei sie keine Eingabe empfangen kann. Dagegen werden bei den OLE-Ausdehnungen Ereignisse, die außerhalb der In-Place-Active-Ansicht auftreten, von dem Server empfangen, ohne daß der Server deaktiviert wird. Obgleich der Server eine Menüauswahl bereitstellen oder einen Doppelklick auf ein anderes Objekt als Signal, das inaktiv wird, interpretieren kann, ist die Standardart, einen Server zu deaktivieren, mit einem <esc>.
Die primäre Schnittstelle, die diese Funktionen ermöglicht, ist IOIeInPlace-Views, auf die der Server, wie unten beschrieben wird, über IOIeIn-Place3DSite::GetWindowContext einen Zeiger erhält.
2.1. IOIeInPlace3DSite
Die IOIeInPlace3DSite-Schnittstelle ist eine Ausdehnung der existierenden OLE-Schnittstelle IOIeInPlaceSite und stellt eine Unterstützung für die "In-Place"-Aktivierung von Software-Anwendungen, die dreidimensionale Objekte erzeugen, bereit. Die IOIeInPlace3DSite-Funktionen werden mit der untenbeschriebenen hinzugefügten Funktionalität in dem gleichen Programmierkontext wie die IOIeIn-PlaceSite-Funktionen verwendet. Genauer ermöglicht die IOIeInPlace3DSite-Schnittstelle, daß Server die dreidimensionalen und Ansichtsinformationen von dem Container erhalten.
25 zeigt die IOIeInPlace3DSite-Schnittstelle 1050 für eine Anwenderschnittstelle 1060 für ein dreidimensionales Objekt. Die Anwenderschnittstelle 1060 enthält eine IUnknown-Schnittstelle 1070, die in allen OLE-Objekten verfügbar ist, und eine IOIeInPlaceSite-Schnittstelle 1080, die in allen OLE-Objekten, die In-Place-aktivieren können, ebenfalls verfügbar ist. Die IUnknown-Schnittstelle 1070 enthält eine Funktion 1090, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlace3DSite-Schnittstelle 1050 zurückgibt, und eine Funktion 1100, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlaceSite-Schnittstelle 1080 zurückgibt. Die IOIeInPlaceSite-Schnittstelle 1080 enthält eine Funktion 1110, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeInPlace3DSite-Schnittstelle 1050 zurückgibt. Die IOIeInPlace3DSite-Schnittstelle 1050 enthält eine GetModelMatrix-Funktion 1120 und eine GetWindowContext-Funktion 1130, wie sie unten beschrieben werden.
26 ist ein Ablaufplan einer Ausführungsform des Prozesses der Bestimmung, ob das dreidimensionale Objekt die In-Place-Aktivierung unterstützt. Während der Initialisierung eines Objekts (z. B. während des Erzeugens oder Ladens eines Objekts) fragt der Container die IUnknown-Funktion 1070 wegen eines Zeigers auf die IOIeInPlace3DSite-Schnittstelle 1050 ab (Schritt 1150). Gleichzeitig fragt der Container die IUnknown-Funktion 1100 wegen eines Zeigers auf die IOIeInPlaceSite-Schnittstelle 1080 ab (Schritt 1160).
In einer bevorzugten Ausführungsform fragt der Container ferner die IOIeInPlaceSite-Funktion 1110 ab, um sicherzustellen, daß es einen Zeiger auf die IOIeInPlace3DSite-Schnittstelle 1050 gibt.
Falls die Abfrage der IOIeInPlaceSite-Funktion 1110 oder der IUnknown-Funktion 1090 einen NULL-Zeiger zurückgibt (Schritt 1170), kann das dreidimensionale Objekt nicht in mehr als einer Ansicht In-Place-aktiviert werden (Schritt 1180). Falls die obigen Abfragen einen Zeiger auf die IOIeInPlace3DSite-Schnittstelle 1050 zurückgeben, kann das dreidimensionale Objekt in mehreren Ansichten In-Place-aktiviert werden (Schritt 1190).
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIeInPlace3DSite-Schnittstelle:
2.1.1 OIeInPlace3DSite::GetModeIMatrix
Die erste OIeInPlace3DSite-Funktion GetModelMatrix ermöglicht, daß ein eingebetteter Server die Befestigungsmatrix zwischen dem Server und dem obersten Container-Koordinatensystem bestimmt. 27 zeigt das allgemeine Konzept der Einbettung eines Servers. In 27 ist ein Objekt 1210 in einen ersten Container 1220 eingebettet, der in einen zweiten Container 1230 eingebettet ist. Um die Positionierung des Objekts 1210 zu ermöglichen, wenn der Server In-Place-aktiv ist, wird eine Befestigungsmatrix zwischen dem zweiten Container 1230 und dem Objekt 1210 berechnet, wobei der erste Container 1220 umgangen wird. 28 ist ein Ablaufplan einer Ausführungsform der IOIeIn-Place3DSite::GetModelMatrix-Funktion. In 28 wird anfangs die Befestigungsmatrix zwischen dem Koordinatensystem des In-Place-aktiven Servers und dem Koordinatensystem des unmittelbar angrenzenden Containers berechnet (Schritt 1250). Daraufhin bestimmt der Server, ob der unmittelbar angrenzende Container der oberste Container ist (Schritt 1260). Wenn das nicht der Fall ist, wird die Befestigungsmatrix zwischen dem unmittelbar angrenzenden Container und dem vorausgehenden Container berechnet und an die Befestigungsmatrix angefügt (Schritt 1270). Die Schritte 1260 und 1270 werden wiederholt, bis die Befestigungsmatrix zwischen dem obersten Container und dem Server berechnet worden ist. Diese Befestigungsmatrix wird daraufhin an den Server übergeben (Schritt 1280).
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen GetModelMatrix-Schnittstelle:
Erhält die Transformationsmatrix von dem äußersten dreidimensionalen Container zu dem inplace-Server.
Diese Funktion wird durch den in-place-Server aufgerufen und rekursiv wiederholt, bis sie den äußersten dreidimensionalen Container erreicht, der die Matrizen verkettet.
2.1.2. OIeInPlace3DSite::GetWindowContext
Die zweite OIeInPlace3DSite-Funktion GetWindowContext stellt eine Schnittstelle zwischen dem äußersten Container und dem In-Place-Server bereit. Wie in 27 gezeigt ist, kann das Objekt 1210 in den ersten Container 1220 eingebettet sein, der in den zweiten Container 1230 eingebettet sein kann. Da das Objekt in mehreren Schichten von Containern eingebettet sein kann, müssen der Server und der oberste Container bei der In-Place-Aktivierung des Servers miteinander kommunizieren, um Systemereignisse zu übergeben. Diese Schnittstelle wird teilweise dadurch erreicht, daß ein Zeiger auf die IOIeInPlaceViews-Schnittstelle des äußersten Containers an das Objekt übergeben wird. Der Zeiger auf IOIeInPlaceViews ist von der Funktion GetWindowContext abgeleitet. Die IOIeIn-PlaceViews-Schnittstelle wird unten beschrieben.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen GetWindowContext-Schnittstelle:
Gibt den Kontext des Fensters des äußersten dreidimensionalen Containers zurück.
Diese Funktion wird rekursiv wiederholt, bis sie den äußersten dreidimensionalen Container erreicht und ihre IOIeInPlaceViews-Schnittstelle an den in-place-Server zurückgibt. Diese Funktion erzeugt den Quittungsaustausch zwischen dem äußersten dreidimensionalen Container und dem dreidimensionalen in-place-Server.
2.2. IOIeInPlaceViews
Die IOIeInPlaceViews-Schnittstelle ist von der (obenbeschriebenen) IOIeInPlace3DSite::GetWindowContext-Funktion abgeleitet und stellt eine Unterstützung für die "In-Place"-Aktivierung von Software-Anwendungen, die dreidimensionale Objekte erzeugen, bereit. Die IOIeInPlaceViews-Funktionen werden mit der untenbeschriebenen hinzugefügten Funktionalität in dem gleichen Programmierkontext wie die IOIeInPlaceUIWindow-Funktionen verwendet. Genauer ermöglicht IOIeInPlaceViews, daß Server von den dreidimensionalen Containern Ansichtsinformationen wie etwa den Ort und die Größe der Ansichten 1010, 1020 und 1030 in 24 erhalten.
29 zeigt die IOIeInPlaceViews-Schnittstelle 1300 für eine Anwenderschnittstelle 1310 für ein dreidimensionales Objekt. Außerdem enthält die Anwenderschnittstelle 1310 eine IOIeInPlaceUIWindow-Schnittstelle 1320, die ermöglicht, daß In-Place-aktive Objekte den Randraum aushandeln, wobei IOIeInPlaceUIWindow die Funktion 1330 enthält. Wie unten beschrieben wird, enthält die IOIeInPlaceViews-Schnittstelle 1300 eine EnumInPlaceViews-Funktion 1340, eine GetViewContext-Funktion 1350 und eine SetActive3DObject-Funktion 1360.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIeInPlaceViews-Schnittstelle:
2.2.1. IOIeInPlaceViews::EnumInPIaceViews
Die erste IOIeInPlaceViews-Funktion EnumInPlaceViews ermöglicht, daß der Server einer Liste der Container-Ansichten empfängt, in denen der Server In-Place-aktiviert ist. Beispielsweise sind in 24 die Ansichten 1010, 1020 und 1030 in der Weise aufgezählt, daß sie die In-Place-Aktivierung des Servers unterstützen.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen EnumInPlaceViews-Schnittstelle:
Gibt die Liste der In-place-Aktiven Fenster in dem Container zurück.
Diese durch dreidimensionale Graphik-Container implementierte Funktion wird durch dreidimensionale In-Place-Server aufgerufen, damit sie die Liste der Ansichten kennen, die von der In-place-Aktivierung betroffen sind. Wenn das Objekt diese Liste besitzt, kann es ihren Kontext anfordern, indem es IOIeInPlace-Views::GetViewContext aufruft.
2.2.2. IOIeInPlaceViews::GetViewContext
Die zweite IOIeInPlaceViews-Funktion GetViewContext ermöglicht, daß der Server eine Transformationsmatrix zwischen dem Koordinatensystem des obersten Containers und der Anzeige (d. h. eine Welt-Ansichts-Matrix) erhält. Mit dieser Transformationsmatrix für jede der In-Place-aktiven Ansichten kennt der Server den richtigen Anzeigekontext auf der Anzeige, weiß er, wie Ereignisse wie etwa Mausklicks auf der Anzeige richtig zu verarbeiten sind, und weiß er, wie dynamische Anzeigen (Gummibandverfahren-Ansichten) in dieser Ansicht auszuführen sind. Um ein (in dem obenbeschriebenen "Inside OLE 2" definiertes) Rangieren zu vermeiden, könnte sich ein Server unter Verwendung der Befestigungsmatrix und der Welt-Ansichts-Matrix selbst anzeigen, um den Kontext für die Server-Ansicht zu bestimmen.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen GetViewContext-Schnittstelle:
Gibt den Graphikkontext des dreidimensionalen In-Place-Fensters zurück.
Diese durch dreidimensionale Graphik-Container implementierte Funktion wird von dreidimensionalen In-Place-Servern aufgerufen, um ihren Anzeigekontext zu initialisieren. Der Zeiger auf die IGL-Schnittstelle ist hier anders. Der Server muß hier die Modellmatrix eines Containers (siehe IOIeIn-Place3DSite::GetModelMatrix) und die pWtoV-Matrix in den Stapelspeicher einspeichern, bevor er dynamisch anzeigt. Nach dem Anzeigen sollte der Server den Kontext wieder aus dem Stapelspeicher holen. Dies ermöglicht, daß der Container (möglicherweise bei einem IAdviseSink::OnViewChange) die Anzeige zu anderen Objekten sendet, ohne sich mit dem Anzeigekontext dieses Objekts zu befassen.
2.2.3. IOIeInPlaceViews::SetActive3DObiect
Die dritte IOIeInPlaceViews-Funktion SetActive3DObject ermöglicht, daß der Server dem Container einen Zeiger auf seine IOIeInPlaceActive3DObject-Schnittstelle gibt, so daß der Container die Ansichten, wie unten beschrieben wird, modifizieren kann.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen SetActive3DObject-Schnittstelle:
Stelle die IOIeInPlaceActive3DObject-Verbindung ein.

E_INVALIDARG Eines der Argumente ist ungültig.

E_UNEXPECTED Es ist ein unerwarteter Fehler aufgetreten.
Um eine direkte Verbindung zwischen dem In-Place-Server und dem Container herzustellen, ruft der Server IOIeInPlace3DSite::GetWindowContext auf und speichert es, woraufhin er IOIeInPlaceViews::SetActive3DObject aufruft und seine Schnittstelle an IOIeInPlaceActive3DObject gibt, so daß der Container seine Verbindung ebenfalls speichern kann.

Obgleich dies für jemanden, der mit der Standard-OLE vertraut ist, nicht erforderlich ist, wird unten zweckmäßig ein ausführlicherer Ablaufplan der inplace-Aktivierung zusammengefaßt, wie er in 35 gezeigt ist. (Anmerkung: Funktionen, die in der Beschreibung nicht beschrieben werden, sind vollständig beschrieben in dem wie obenbeschriebenen "Inside OLE 2"): Beim Empfang von IOIeObject::DoVerb (oder IOIe3DObject::DoVerb) ruft der Server folgendes auf:

IOIeClientSite::Querylnterface	Für die IOIeInPlaceSite-Schnittstelle, und speichert sie.
IOIeInPlaceSite::Querylnterface	Für die IOIeInPlace3DSite-Schnittstelle, und speichert sie.
IOIeInPlaceSite::CanInPlaceActivate,	Fragt, ob der Container die In-Place-Aktivierung unterstützt.
IOIeInPlace3DSite::GetModelMatrix	Um die ModelMatrix (vom äußersten Container zum Server) zu erhalten.

Diese Aufrufe werden rekursiv wiederholt, bis sie den äußersten dreidimensionalen Container erreichen.

IOIeInPlaceSite::OnInPIaceActivate	Um den Container zu benachrichtigen, daß das Objekt im Begriff ist, aktiviert zu werden.
IOIeInPlaceSite::OnUlActivatate	Um den Container zu benachrichtigen,daß die Menüs zusammengeführt werden.
IOIeInPlaceSite::GetWindowContext	Um die IOIeInPlaceFrame- und die IOIeInPlaceUIWindow-Schnittstelle zurückzugeben.

IOIeInPlace3DSite::GetWindowContext	Um die IOIeInPlaceViews-Schnittstelle (Fenstermanager) zurückzugeben.
CreateMenu, um ein leeres Menü zu erzeugen. IOIeInPlaceFrame::InsertMenus	um anzufordern, daß der Container seine Menüs einsetzt.
InsertMenus, um seine eigenen Menüs einzusetzen. IOIeInPlaceUIWindow::SetActiveObject	Um dem Container einen Zeiger auf sein IOIeInPlaceActiveObject zu geben.
IOIeInPlaceViews::SetActive3DObject	Um dem Container einen Zeiger auf sein IOIeInPlaceActive3DObject zu geben.
IOIeInPlaceViews::EnumInPIaceViews	Um die Liste der Container-Ansichten zu erhalten.
IOIeInPlaceViews::GetViewsContext	Um für jede Ansicht den Ansichtskontext zu erhalten.
IOIeInPlaceFrame::SetMenu	Um im Rahmen des Containers das zusammengesetzte Rahmenmenü einzustellen.

2.3. IOIeInPlaceActive3DObiect
Die IOIeInPlaceActive3DObject-Schnittstelle ermöglicht, daß der Container das In-Place-aktive Objekt über irgendwelche Ansichtsänderungen, -löschungen oder -erzeugungen informiert. Die IOIeInPlaceActive3DObject-Schnittstelle ist eine Ausdehnung der IOIeInPlaceActiveObjeect-Schnittstelle und wird durch dreidimensionale Container implementiert, die die In-Place-Aktivierung unterstützen.
Die IOIeInPlaceActive3DObject-Funktionen werden in dem gleichen Programmierkontext wie die IOIeInPlaceActiveObject-Funktionen verwendet, wobei sie, wie unten beschrieben wird, die Funktionalität zum Benachrichtigen des Servers über mehrere Ansichten hinzufügen. Die IOIeInPlaceActive3DObject-Schnittstelle ist wie oben beschrieben von IOIeInPlaceViews::SetActive3DObject abgeleitet.
30 zeigt eine IOIeInPlaceActive3DObject-Schnittstelle 1380 für eine Anwenderschnittstelle 1390. Die Anwenderschnittstelle 1390 enthält die IOIeInPlaceActiveOBject-Schnittstelle 1400. Wie unten beschrieben wird, enthält die IO-IeInPlaceActive3DObject-Schnittstelle 1380 eine OnInPlaceViewChange-Funktion 1410, eine OnInPlaceViewChange-Funktion 1420 und eine OnInPlaceViewDelete-Funktion 1430.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIeInPlaceActive3DObject-Schnittstelle:
2.3.1. IOIeInPlaceActive3DObiect::OnInPIaceViewChange
Die erste IOIeInPlaceActive3DObject-Funktion OnInPlaceViewChange wird verwendet, wenn der äußerste dreidimensionale Container eine seiner In-Place-Ansichten modifiziert. Ein Beispiel ist, wenn die Position der Ansichten 1020 und 1030 in 24 umgeschaltet wird. Der Container ruft in Reaktion OnInPlace-ViewChange auf, das den In-Place-Server über die Änderung in den Transformationsmatrizen zwischen der Positionierung der Ansichten in dem Container und in dem Server benachrichtigt.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen OnInPlaceViewChange-Schnittstelle: IOIeInPlaceActive3DObject::OnInPlaceViewChange
Der in-place-Server muß diese Informationen aufbewahren. Eine Matrix (ViewTo-World) wird für Lokalisierungszwecke verwendet, während die andere (WorldTo-View) zur dynamischen Anzeige verwendet wird. Diese zwei Matrizen werden übergeben, da sie die Perspektive oder die Projektion transportieren könnten und singulär sein können, so daß die eine nicht durch Inversion aus der anderen deduziert werden könnte.
2.3.2. IOIeInPlaceActive3DObiect::OnInPlaceViewChange
Die zweite IOIeInPlaceActive3DObject-Funktion OnInPlaceViewCreate wird verwendet, wenn der äußerste dreidimensionale Container eine neue Ansicht des Objekts zu dem Container hinzufügt. Ein Beispiel ist, wenn der Container über der Position 1030 in 24 eine andere Ansicht des Objekts 1000 hinzufügt. In Reaktion darauf ruft der Container OnInPlaceViewChange auf, das den In-Place-Server über die neue Ansicht benachrichtigt.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen OnInPlaceViewCreate-Schnittstelle:
sBenachrichtigt das In-Place-Objekt, das der äußerste dreidimensionale Container gerade ein neues In-Place-Aktives Fenster erzeugt hat.
Daraufhin ruft der in-place-Server IOIeInPlaceViews::GetViewContext auf, um den neuen Anzeigekontext zu erhalten, und speichert ihn.
2.3.3. IOIeInPlaceActive3DObiect::OnInPlaceViewDelete
Die dritte IOIeInPlaceActive3DObject-Funktion OnInPlaceViewDelete wird verwendet, wenn der äußerste dreidimensionale Container eine Ansicht eines Objekts für den Container löscht. Beispielsweise ruft der Container OnInPlace-ViewDelete auf, wenn die Ansicht 1010 des Objekts 1000 in 24 gelöscht wird, wobei er den In-Place-Server benachrichtigt, daß er die Anzeige dieser Ansicht anhalten soll.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen OnInPlaceViewDelete-Schnittstelle:
Benachrichtigt das In-Place-Objekt, daß der äußerste dreidimensionale Container gerade eine Ansicht gelöscht hat, die an der In-Place-Aktivierung beteiligt ist.

E_UNEXPECTED Es ist ein unerwarteter Fehler aufgetreten.
Daraufhin entfernt der in-place-Server diese Ansicht aus seiner "Liste aktiver Ansichten" und gibt den unbrauchbaren Kontext frei.
3. Schnittstellen, die die Wechselwirkung dreidimensionaler Objekte ermöglichen
Die neuen OLE-Schnittstellen, wie sie hier beschrieben werden, ermöglichen, daß dreidimensionale Objekte in dem Container-Koordinatensystem miteinander in Wechselwirkung treten. Wenn Anwendungen dreidimensionale Objekte in einem Container/Dokument in komplizierten Beziehungen kombinieren, so daß sie richtig in Wechselwirkung treten, müssen die Objekte die räumlichen Informationen der Oberflächen in anderen Objekten nutzen. Dieses "Zusammenwirken" zwischen Objekten erstreckt sich darauf, daß ermöglicht wird, daß ein Objekt die "Elemente", die ein anderes Objekt bilden, "ermittelt". Was mit diesen Informationen getan wird, ist dem Anwender oder der Server-Anwendung überlassen. Ferner ermöglicht das Zusammenwirken, daß sich überlappende Objekte während komplizierter Präzisionsbeziehungsmanipulationen die Position und Geometrie voneinander nutzen. Ein übliches Beispiel umfaßt, daß der Anwender ein geometrisches Element in bezug auf die Geometrie eines anderen Objekts (oder Elements in dem Container) manipulieren möchte.
31 zeigt die IOIeLocate-Schnittstelle 1440 für eine Anwenderschnittstelle 1450 eines Objekts. Die Anwenderschnittstelle 1450 enthält eine IOIeItem-Container-Schnittstelle 1460, die auch für OLE-Objekte verfügbar ist. Die IOIeItemContainer-Schnittstelle 1460 enthält eine Funktion 1470, die, wenn sie aufgerufen wird, einen Zeiger auf die IOIeLocate-Schnittstelle 1440 zurückgibt, falls das Objekt räumliche Informationen zurückgeben kann. Wie unten beschrieben wird, enthält die IOIeLocate-Schnittstelle 1440 eine PointLocate-Funktion 1480, eine ShapeLocate-Funktion 1490 und eine IOIeItemContainer-Funktion 1500.
Um IOIeLocate zu verwenden, muß der Server sicherstellen, daß die Funktion 1470 einen Zeiger auf die IOIeLocate-Schnittstelle 1460 zurückgeben kann. Ähnlich muß die IOIeLocate-Funktion 1500 auch einen Zeiger auf die IOIeItemContainer-Schnittstelle 1460 zurückgeben, so daß der Container andere (nicht gezeigte) IOIeItemContainer-Funktionen wie etwa EnumObjects und Parse-DisplayName nutzen kann. Falls der Server lediglich den Ort des Objekts selbst und nicht den der "Elemente" des Objekts unterstützt, braucht sich IOIeLocate nicht mit IOIeItemContainer zu befassen.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen IOIeLocate-Schnittstelle und der Variablentypdefinitionen:
3.1 IOIeLocate:PointLocate
Die erste IOIeLocate-Funktion PointLocate ermöglicht, daß ein Server eine Liste von "Elementen" in einem anderen Objekt erhält, die eine anwenderdefinierte Bohrungslinie im Raum schneiden.
32 ist ein Ablaufplan einer Ausführungsform des Prozesses des Lokalisierens von Elementen in einem Objekt unter Verwendung der PointLocate-Funktion.
Zunächst definiert der Anwender eine Bohrungslinie in dem Container-Koordinatensystem (Schritt 1520). Nachfolgend wird IOIeLocate:PointLocate aufgerufen, wobei die anderen Server auf diese Funktion damit reagieren, daß sie bestimmen, welche Stücke von ihm (Elemente) die Bohrungslinie schneiden (Schritt 1530). Elemente, die die Kriterien erfüllen, werden als eine Liste von Monikern zurückgegeben (Schritt 1540). (Alternativ kann das Objekt einfach alle seine Elemente zurückgeben.) Wenn die Liste der Moniker zurückgegeben worden ist, ruft der Server die (in den Anhängen beschriebene) BindMoniker-Helferfunktion oder IMoniker::BindToObject auf, um jedes Moniker zu binden, d. h. jedes Element in ein einzelnes Objekt umzusetzen (Schritt 1550). Daraufhin kann jedes neue Objekt, das die definierte Bohrungslinie schneidet, durch den Server für irgendeinen Zweck verwendet werden.
Die 34a-34c zeigen die Verwendung der IOIeLocate::PointLocate-Funktion. 34a enthält ein erstes Objekt 1590, eine Schraube, ein zweites Objekt 1600, einen Block mit den Oberflächen 1610 und 1620 und eine Bohrungslinie 1630. 34b enthält ein erstes Objekt 1640 und ein zweites Objekt 1650. 34c enthält ein modifiziertes erstes Objekt 1660, eine Schraube und einen Block 1600. Die Schraube 1590 wurde in einer ersten Software-Anwendung erzeugt und in den Container, der den Block 1600 erzeugt hat, übertragen.
Ohne die IOIeLocate::PointLocate-Funktion sind die Schraube 1590 und der Block 1600 ohne irgendeine Kenntnis voneinander einfach in dem Container. Mit der IOIeLocate::PointLocate-Funktion empfängt beispielsweise die Schraube 1590 Informationen in bezug auf andere Objekte in dem Container. Wenn der Anwender, wie in 34a gezeigt ist, die Länge der Schraube 1590 erhöhen möchte, bis sie den Block 1600 berührt, definiert der Anwender zunächst entlang der Achse der Schraube 1590 die Bohrungslinie 1630. Daraufhin ruft der Server, wie in 32 offenbart ist, IOIeLocate::PointLocate auf. Wie in 34a gezeigt ist, schneidet sich die Bohrungslinie mit den Oberflächen 1610 und 1620 des Blocks 1600, so daß die IOIeLocate::PointLocate-Funktion die Moniker für diese Oberflächen zurückgibt. Wie in 34b gezeigt ist, wird jedes Moniker daraufhin in ein erstes Objekt 1640 und in ein zweites Objekt 1650 umgesetzt. Da der Server nun die Koordinaten des ersten Objekts 1640 und des zweiten Objekts 1650 kennt, kann der Anwender die Länge der Schraube 1590 erhöhen, bis die modifizierte Schraube 1660, wie in 34c gezeigt ist, den Block 1600 berührt.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen PointLocate-Schnittstelle:
Erhält eine Liste sämtlicher Elemente eines Objekts, die sich mit einem Punkt oder mit einer Bohrungslinie schneiden.
Gib einem Enumerator der Moniker zurück. Dieses Moniker kann in ein DataObject umgesetzt werden.
3.2 IOIeLocate:ShapeLocate
Die zweite IOIeLocate-Funktion ShapeLocate ermöglicht, daß ein Server eine Liste von "Elementen" in einem anderen Objekt erhält, das sich mit einer anwenderdefinierten Form im Raum schneidet.
33 ist ein Ablaufplan einer Ausführungsform des Prozesses des Lokalisierens von Elementen in einem Objekt unter Verwendung der ShapeLocate-Funktion.
Zunächst definiert der Anwender eine Form in dem Container-Koordinatensystem (Schritt 1570). Nachfolgend wird IOIeLocate:ShapeLocate aufgerufen, wobei die anderen Server auf diese Funktion damit reagieren, daß sie bestimmen, welche Stücke von ihm (Elemente) die Bohrungslinie schneiden (Schritt 1580). Die Elemente, die die Kriterien erfüllen, werden als eine Liste von Monikern zurückgegeben (Schritt 1590). (Alternativ kann das Objekt einfach alle seine Elemente zurückgeben.) Wenn die Liste der Moniker zurückgegeben worden ist, ruft der Server die BindMoniker-Helferfunktion oder IMoniker::BindToObject auf, um jedes Moniker zu binden, d. h. jedes Element in ein einzelnes Objekt umzusetzen (Schritt 1600). Jedes Objekt, das die definierte Form schneidet, kann von dem Server für irgendeinen Zweck verwendet werden. Im Betrieb arbeitet die IOIeLocate::ShapeLocate-Funktion auf die gleiche Weise, wie in den 34a-34c gezeigt ist.
Das folgende ist eine Beschreibung der bevorzugten Ausführungsform der formalen ShapeLocate-Schnittstelle:
Erhält eine Liste sämtlicher Elemente, die eine Form schneiden/in einer Form enthalten sind.
Gib einen Enumerator des Monikers zurück. Dieses Moniker kann in ein DataObject umgesetzt werden.

Claims

Verfahren zum Aufrufen von Software-Objekten in einem Computersystem, das einen computerlesbaren Speicher (66, 67) besitzt, unter Verwendung der Verknüpfung und Einbettung von Objekten, wobei das Verfahren die folgenden Schritte umfaßt: (a) Erzeugen einer Datenstruktur in einem ersten Software-Anwendungsprogramm, wobei die Datenstruktur Daten speichert, die ein Objekt (330) beschreiben, wobei die Daten zweidimensionale Daten für das Objekt (330) und eine Implementierung eines zweidimensionalen Verfahrens, das als Parameter dem Objekt (330) entsprechende zweidimensionale Daten verwendet, enthalten; (b) Speichern der Datenstruktur im computerlesbaren Speicher (66, 67); (c) Wiedergewinnen der Datenstruktur aus dem computerlesbaren Speicher (66, 67) in einem zweiten Software-Anwendungsprogramm; (d) Berechnen einer Matrix unter Verwendung des zweiten Software-Anwendungsprogramms, die die Daten in einem zweidimensionalen Koordinatensystem auf eine Ebene mit einer Orientierung in einem dreidimensionalen Koordinatensystem (180) in dem zweiten Software-Anwendungsprogramm abbildet, wobei das zweidimensionale Koordinatensystem eine Position des Objekts (330) in dem ersten Software-Anwendungsprogramm definiert, (e) Anzeigen einer Ansicht (320) des Objekts (330) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der Matrix; und (f) Ändern der Orientierung des Objekts (330) in bezug auf das dreidimensionale Koordinatensystem (180) in dem zweiten Software-Anwendungsprogramm unter Verwendung des zweidimensionalen Verfahrens.
Verfahren nach Anspruch 1, das ferner umfaßt: Bestimmen von Ausdehnungskoordinaten für das Objekt (330) aus dem zweiten Software-Anwendungsprogramm heraus.
Verfahren nach Anspruch 2, bei dem die Bestimmung der Ausdehnungskoordinaten für das Objekt (330) aus dem zweiten Software-Anwendungs programm heraus umfaßt: Bestimmen der Ausdehnungskoordinaten für das Objekt (330) unter Verwendung der Matrix, die auf der Grundlage der zweidimensionalen Daten für das Objekt (330) berechnet wird; und Zurückführen der Ausdehnungskoordinaten für das Objekt (330) zu dem zweiten Software-Anwendungsprogramm.
Verfahren nach einem der Ansprüche 1 bis 3, das ferner umfaßt: Manipulieren einer Ansicht des Objekts (330) in dem zweiten Software-Anwendungsprogramm unter Verwendung der zweidimensionalen Daten für das Objekt (330).
Verfahren nach einem der Ansprüche 1 bis 4, bei dem die Änderung der Orientierung des Objekts (330) in bezug auf das dreidimensionale Koordinatensystem (180) in dem zweiten Software-Anwendungsprogramm unter Verwendung des zweidimensionalen Verfahrens ferner umfaßt: Aktivieren des ersten Software-Anwendungsprogramms aus dem zweiten Software-Anwendungsprogramm heraus; und Ändern eines Dimensionsattributs des Objekts (330) in dem ersten Software-Anwendungsprogramm, das aus dem zweiten Software-Anwendungsprogramm heraus aktiviert wird.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem das Anzeigen einer Ansicht des Objekts (330) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der Matrix das Aufrufen eines Ansichterzeugungsvertahrens umfaßt, das das Anzeigen einer Ansicht des Objekts (330) auf der Grundlage der das Objekt (330) beschreibenden Daten bewirkt.
Verfahren nach einem der Ansprüche 1 bis 6, bei dem das Anzeigen einer Ansicht des Objekts (330) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der Matrix das Aufrufen eines Ansichtlöschungsvertahrens umfaßt, daß das Löschen einer Ansicht des Objekts (330) bewirkt.
Verfahren nach einem der Ansprüche 1 bis 7, bei dem das Anzeigen einer Ansicht des Objekts (330) in dem zweiten Software-Anwendungsprogramm auf der Anzeige (61) unter Verwendung der Matrix das Aufrufen eines Formlokalisierungsvertahrens umfaßt, das ein Moniker eines Elements im Objekt (330) in Reaktion auf eine Form im dreidimensionalen Raum vom zweiten Software-Anwendungsprogramm erzeugt.
Verfahren zum Aufrufen von Software-Objekten in einem Computersystem mit einem computerlesbaren Speicher (66, 67) unter Verwendung der Verknüpfung und Einbettung von Objekten, wobei das Verfahren die folgenden Schritte umfaßt: (a) Erzeugen einer Datenstruktur in einem ersten Software-Anwendungsprogramm, die Daten speichert, die ein Objekt (310; 40; 470) beschreiben, wobei die Daten dreidimensionale Daten für das Objekt (310; 40; 470) und eine Implementierung eines dreidimensionalen Verfahrens, das als Parameter dem Objekt (310; 40; 470) entsprechende dreidimensionale Daten verwendet, enthalten; (b) Speichern der Datenstruktur im computerlesbaren Speicher (66, 67); (c) Wiedergewinnen der Datenstruktur aus dem computerlesbaren Speicher (66, 67) in einem zweiten Software-Anwendungsprogramm; (d) und entweder (1) Berechnen einer ersten Matrix unter Verwendung des zweiten Software-Anwendungsprogramms, die die Daten in einem ersten dreidimensionalen Koordinatensystem (170) in eine Orientierung in einem zweiten dreidimensionalen Koordinatensystem (180) in dem zweiten Software-Anwendungsprogramm abbildet, wobei das erste dreidimensionale Koordinatensystem (170) eine Position des Objekts (40) in dem ersten Software-Anwendungsprogramm definiert, (2) Anzeigen einer Ansicht des Objekts (40) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der Matrix und (3) Ändern der Orientierung des Objekts (40) in bezug auf das zweite dreidimensionale Koordinatensytem (180) in dem zweiten Software-Anwendungsprogramm unter Verwendung des dreidimensionalen Verfahrens; oder (1) Berechnen einer zweiten Matrix unter Verwendung des zweiten Software-Anwendungsprogramms, die die Daten in dem ersten dreidimensionalen Koordinatensystem (170) in eine Orientierung in einem zweidimensionalen Koordinatensystem in dem zweiten Software-Anwendungsprogramm abbildet, (2) Anzeigen einer Ansicht des Objekts (470) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der zweiten Matrix und (3) Ändern der Orientierung des Objekts (470) in bezug auf das zweidimensionale Koordinatensystem (170) in dem zweiten Software-Anwendungsprogramm unter Verwendung des dreidimensionalen Verfahrens.
Verfahren nach Anspruch 9, das ferner umfaßt: Bestimmen von Ausdehnungskoordinaten für das Objekt (310; 40; 470) aus dem zweiten Software-Anwendungsprogramm heraus.
Verfahren nach Anspruch 10, bei dem die Bestimmung der Ausdehnungskoordinaten für das Objekt (310; 40; 470) aus dem zweiten Software-Anwendungsprogramm heraus umfaßt: Bestimmen der Ausdehnungskoordinaten für das Objekt (310; 40; 470) auf der Grundlage der ersten oder der zweiten Matrix, die unter Verwendung der dreidimensionalen Daten für das Objekt (310; 40; 470) bestimmt wird.
Verfahren nach Anspruch 10 oder 11, das ferner umfaßt: Manipulieren der Ansicht des Objekts (310; 40; 470) in dem zweiten Software-Anwendungsprogramm unter Verwendung der dreidimensionalen Daten für das Objekt (310; 40; 470).
Verfahren nach einem der Ansprüche 10 bis 12, bei dem die Änderung der Orientierung des Objekts (310; 40; 470) in bezug auf das zweite dreidimensionale Koordinatensystem (180) in dem zweiten Software-Anwendungsprogramm unter Verwendung des dreidimensionalen Verfahrens ferner umfaßt: Aktivieren des ersten Software-Anwendungsprogramms aus dem zweiten Software-Anwendungsprogramm heraus; und Ändern eines Dimensionsattributs des Objekts (310; 40; 470) in dem ersten Software-Anwendungsprogramm, das aus dem zweiten Software-Anwendungsprogramm heraus aktiviert wird.
Verfahren nach einem der Ansprüche 10 bis 13, bei dem das Anzeigen einer Ansicht des Objekts (310; 40; 470) in dem zweiten Software-Anwendungsprogramm auf der Anzeige (61) unter Verwendung der ersten Matrix das Aufrufen eines Ansichtänderungsverfahrens umfaßt, das die Änderung einer ersten Ansicht des Objekts (310; 40; 470) zu einer zweiten Ansicht auf der Grundlage der das Objekt (310; 40; 470) beschreibenden Daten bewirkt.
Verfahren nach einem der Ansprüche 10 bis 14, bei dem das Anzeigen einer Ansicht des Objekts (310; 40; 470) in dem zweiten Software-Anwendungsprogramm auf der Anzeige (61) unter Verwendung der ersten Matrix das Aufrufen eines Punktlokalisierungsverfahrens umfaßt, das ein Moniker eines Elements im Objekt (310; 40; 470) in Reaktion auf einen Ort in bezug auf das zweite dreidimensionale Koordinatensystem (180) erzeugt.
Verfahren nach einem der Ansprüche 10 bis 15, bei dem das Anzei gen einer Ansicht des Objekts (310; 40; 470) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der zweiten Matrix das Aufrufen eines Ansichterzeugungsverfahrens umfaßt, das die Anzeige einer Ansicht des Objekts (310; 40; 470) auf der Grundlage der das Objekt (310; 40; 470) beschreibenden Daten bewirkt.
Verfahren nach einem der Ansprüche 10 bis 16, bei dem das Anzeigen einer Ansicht des Objekts (310; 40; 470) in dem zweiten Software-Anwendungsprogramm auf einer Anzeige (61) unter Verwendung der zweiten Matrix das Aufrufen eines Ansichtlöschungsverfahrens umfaßt, daß das Löschen einer Ansicht des Objekts (310; 40; 470) bewirkt.