DE69400204T2

DE69400204T2 - Ladesystem

Info

Publication number: DE69400204T2
Application number: DE69400204T
Authority: DE
Inventors: David Goldsmith; Andrew Heninger; Christopher Moeller; Arnold Schaeffer
Original assignee: Taligent Inc
Current assignee: Object Technology Licensing Corp
Priority date: 1993-02-26
Filing date: 1994-01-06
Publication date: 1997-01-09
Anticipated expiration: 2014-01-07
Also published as: JPH08508355A; CA2135518A1; AU6228594A; DE69400204D1; WO1994019740A1; EP0664902B1; JP3602532B2; EP0664902A1; US5519862A; CA2135518C

Description

Copyright-Hinweis

Diese Patentanmeldung enthält urheberrechtlich geschütztes Material, dessen Reproduktion nur als Teil der Patentanmeldung zu informativen Zwecken gestattet ist. Alle anderen Rechte, insbesondere das Recht zur kommerziellen Verwertung derartigen Materials, sind vorbehalten.

Bereich der Erfindung

Die vorliegende Erfindung betrifft im allgemeinen Computerdokumente und insbesondere die gleichzeitige Verwendung von Rahmenwerken in einem objektorientierten Betriebssystem.

Hintergrund der Erfindung

Für Entwickler von Workstation-Software wird es zunehmend wichtiger, eine flexible Software-Umgebung zu schaffen und gleichzeitig die Konsistenz in der Anwenderschnittstelle zu gewährleisten. Ein früher Versuch, diese Art von Betriebsumgebung zu schaffen, ist im US-Patent 4.686.522 für Hernandez et al. offenbart. Dieses Patent diskutiert ein kombiniertes Grafik- und Textverarbeitungssystem, in welchem ein Anwender ein dynamisches Menü an der Stelle des Cursors aufrufen und eine Vielzahl unterschiedlicher Funktionen aus diesem Menü auswählen kann. Diese Art der natürlichen Interaktion mit einem Anwender verbessert die Anwenderschnittstelle und macht die Anwendung viel intuitiver.
Ein bekanntes Verfahren für das Laden von Anwendungen in einem objektorientierten Betriebssystem wird in Byte, Vol 16, Nr. 2, Feb. 1991, Seite 211-221, diskutiert. Das Dokument offenbart ein Betriebssystem für ein Notebook- Computersystem, das einen Lader für objektorientierte Anwendungsprogramme verwendet. Es wird ein Beispiel für ein in ein Anwendungsprogramm eingebettetes Anwendungsprogramm diskutiert. Beim Betriebssystem handelt es sich um eine Multitasking-Umgebung, die jedoch keine Steuerung fur gleichzeitige Anwendungen auf zwei oder mehreren Systemen zur Verfügung stellt. Weitere Beispiele objektorientierter Umgebungen umfassen Informationstechnik it, Vol 34, Seiten 102-112, Feb. 1992, worin Vererbung und andere objektorientierte Techniken zum Erstellen neuer Programmiermuster unter Verwendung objektorientierter Werkzeuge diskutiert werden; und Unit Textwindows, Seiten 1-13, von Pure Software GmbH, 1992, worin ein Beispiel für eine objektorientierte Anwendung zur Steuerung eines Fensters an einer Anzeige offenbart wird. Objektorientierte Anwendungen sollten jedoch auch eine konsistente Interaktionsschnittstelle mit dem Anwender darstellen, und zwar unabhängig davon, welche Anwendung derzeit gerade aktiv ist, und wieviele Anwender gleichzeitig die Anwendung benutzen. Keine der Bezugnahmen des Standes der Technik, die dem Antragsteller bekannt sind, verfügt über jene innovativen Hardware- und Softwaresystemeigenschaften, mit deren Hilfe alle objektorientierten Anwendungen auf eine konsistente Art und Weise arbeiten können.

Zusammenfassung der Erfindung

Die vorliegende Erfindung beseitigt die Mängel des Standes der Technik, indem sie ein System und ein Verfahren zur Synchronisierung einer Anwendung oder von Anwendungen schafft, die auf einem oder mehreren Computersystemen läuft/laufen. Die Anwendungen beginnen den Betrieb in einem konsistenten Zustand, und die Konsistenz wird durch das Verteilen von Befehlen an die einzelnen Anwendungen beibehalten, während diese in einem Steuerungssystem eingegeben werden. Weitere Ausführungsformen verwalten mehr als ein System durch die Eingabe und das Verteilen von Befehlen. Es werden auch Vorkehrungen zur Eingabe von Befehlen an einem einzelnen System getroffen, welche die Anwendung nicht verändern, sondern nur das einzelne System betreffen. Es wird eine Modellverfolgung verwendet, um Befehle zu verfolgen und sie auf konsistente Art und Weise in der gesamten Mehrzahl an Computersystemen anzuwenden.

Kurze Beschreibung der Zeichnungen

Figur 1A ist ein Blockdiagramm eines Personal-Computer- Systems gemäß der vorliegenden Erfindung;
Figur 1B ist eine Anzeige gemäß der vorliegenden Erfindung;
Figur 2 zeigt die Werkzeuge, die zur Erstellung einer Anwendung gemäß der vorliegenden Erfindung verwendet werden;
Figur 3 ist ein Flußdiagramm einer Befehlsverarbeitung gemäß der vorliegenden Erfindung;
Figur 4 ist eine Auswahlfeldsteuerung gemäß der vorliegenden Erfindung;
Figur 5 ist eine Auswahlfeldsteuerungsaktivierung gemäß der vorliegenden Erfindung;
Figur 6 ist eine Auswahlfeld-Aktualisierung gemäß der vorliegenden Erfindung;
Figur 7 ist eine Zusammenfassung der Auswahlfeldsteuerungsverarbeitung gemäß der vorliegenden Erfindung;
Figur 8 ist eine Darstellung eines Kontrollfeldes gemäß der vorliegenden Erfindung;
Figur 9 ist eine Abbildung einer Dialogbox gemäß der vorliegenden Erfindung;
Figur 10 ist eine Abbildung eines Dialogbox-Farbreglers gemäß der vorliegenden Erfindung;
Figur 11 ist eine Abbildung eines Radioknopfes gemäß der vorliegenden Erfindung;
Figur 12 ist ein detailliertes Flußdiagramm der Menüzustandsverarbeitung gemäß der vorliegenden Erfindung;
Figur 13 ist ein Bild einer Anzeige gemäß der vorliegenden Erfindung;
Figur 14 zeigt die detaillierte Logik der atomischen Ausführung gemäß der vorliegenden Erfindung;
Figur 15 ist eine Fortsetzung der detaillierten Logik im Zusammenhang mit der intelligenten Beschriftungsverarbeitung gemäß der vorliegenden Erfindung;
Figur 16 zeigt die detaillierte Logik der intelligenten Fensterbeschriftungsverarbeitung gemäß der vorliegenden Erfindung;
Figur 17 zeigt, wie gemäß der vorliegenden Erfindung Objekte erzeugt werden, und wie die Objekte miteinander während einer typischen Interaktion mit einem Objekt miteinander kommunizieren, das bewegt und ausgewählt werden kann;
Figur 18 ist ein Objekt, das ein Meldungs-Flußdiagramm für ein Meldungs-Quellobjekt gemäß der vorliegenden Erfindung erzeugt;
Figur 19 zeigt ein Flußdiagramm, das die detaillierte Logik im Zusammenhang mit der Auswahl des geeigneten Anwenderschnittstellenelementes gemäß der vorliegenden Erfindung darstellt;
Figur 20 ist ein Flußdiagramm, das die detaillierte Logik im Zusammenhang mit dem Bildlauf gemäß der vorliegenden Erfindung darstellt;
Figur 21A, 21B und 21C zeigen den Fenster-Bildlauf gemäß der vorliegenden Erfindung;
Figur 22 ist eine Darstellung der Klassenhierarchie für die Task-Steuerung gemäß der vorliegenden Erfindung;
Figur 23 zeigt den Vorgang zur Erstellung eines Haupttasks an einem anderen Team durch TTeamHandle;
Figur 24 ist ein Flußdiagramm der detaillierten Logik gemäß der vorliegenden Erfindung;
Figur 25 ist ein Diagramm einer typischen Verfolgungsschleife, wie sie in Systemen des Standes der Technik, wie zum Beispiel dem Apple Macintosh, verwendet werden;
Figur 26 zeigt ein Beispiel einer abstrakten Verfolgungsschleife gemäß der vorliegenden Erfindung; und
Figur 27 zeigt ein Beispiel einer modellbasierten Verfolgungsschleife gemäß der vorliegenden Erfindung.

GENAUE BESCHREIBUNG DER ERFINDUNG

Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel einem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1A dargestellt, welche eine typische Hardware-Konfiguration einer Workstation gemäß der vorliegenden Erfindung darstellt und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1A dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A-Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel Disketteneinheiten 20, am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß eines Anzeigegerätes 38 am Bus. Typischerweise befindet sich auf der Workstation ein Betriebssystems, wie zum Beispiel das Betriebssystem IBM OS/2 Betriebssystem oder das Apple System/7 -Betriebssystem.
Bei der vorliegenden Erfindung handelt es sich um eine neue, objektorientierte Systemsoftware-Plattform, die sich aus einem Betriebssystem und einem Entwicklungssystem zusammensetzt, das so konstruiert ist, daß es die Personal- Computer-Anwendung für die Endanwender und Systemverkäufer revolutioniert. Bei dem System handelt es sich um ein vollständiges, freistehendes, natives Betriebssystem und Entwicklungssystem, das von Grund auf für Hochleistungsanwendungen auf Personal Computern konstruiert ist. Die Erfindung ist ein zur Gänze objektorientiertes System mit einer Vielzahl an Rahmenwerken, Klassenbibliotheken und einer Objektprogrammierungsumgebung einer neuen Generation, um die Wirtschaftlichkeit einer Anwendungssoftwareentwicklung von dritter Seite grundlegend zu verbessern. Bei der vorliegenden Erfindung handelt es sich um ein zur Gänze übertragbares Beriebssystem.
Herkömmliche Betriebssysteme stellen eine Anzahl von Dienstleistungen zur Verfügung, die Software-Entwickler verwenden können, um ihre Software herzustellen. Deren Programme sind sehr lose in die gesamte Betriebssystemumgebung integriert. DOS-Anwendungen zum Beispiel übernehmen die gesamte Maschine. Dies bedeutet, daß für den Anwender diese Anwendung zum Betriebssystem wird. In Macintosh - und Windows-Betriebssystemen sehen die Anwendungen ähnlich aus und verfügen über zahlreiche Gemeinsamkeiten, und typischerweise unterstützen sie das Ausschneiden und Einfügen zwischen Anwendungen. Dies macht es im allgemeinen für die Anwender einfacher, mehrere Anwendungen in einer einzigen Umgebung zu verwenden. Da jedoch die Gemeinsamkeit nicht in einer Reihe von Dienstleistungen und Rahmenwerken festgelegt ist, ist es immer noch sehr schwierig, Software zu entwickeln.
In der vorliegenden Erfindung wird mit dem Begriff "Anwendung" die Erstellung einer Reihe von Zielen bezeichnet, die in die Betriebssystemumgebung integriert werden. Software-Entwickler sind sowohl bezüglich einer hochentwikkelten Reihe von Dienstleistungen als auch bezüglich eines Rahmenwerkes vom Betriebssystem abhängig, um Software zu entwickeln. Die Rahmenwerke in der vorliegenden Erfindung ermöglichen mächtige Abstraktionen, die es Software- Entwicklern möglich machen, sich auf ihr Problem zu konzentrieren, anstatt eine Infrastruktur aufzubauen. Darüberhinaus sind die grundlegenden Abstraktionen für die Software- Entwickler jenen grundlegenden Konzepten sehr ähnlich, die ein Anwender verstehen muß, um die Software bedienen zu können. Diese Architektur führt zu einer einfacheren Entwicklung hochentwickelter Anwendungen.
Dieser Abschnitt beschreibt vier Schritte zum Schreiben von Software unter Anwendung der vorliegenden Erfindung. Ein Anwender, der die Entwicklung einer Anwendung überlegt, stellt sich typischerweise die folgenden Fragen:
Was modelliere ich?
Bei einer Textverarbeitung ist dies der Text, den ich eingebe; bei einer Tabellenkalkulation sind dies die Werte und Formeln in den Zellen.
Wie werden die Daten dargestellt?
Bei einer Textverarbeitung werden die Zeichen typischerweise in einem WYSIWYG-Format (what-you-see-is-whatyou-get = die Darstellung am Bildschirm entspricht der Darstellung am Ausdruck) am Bildschirm mit entsprechenden Zeilen- und Seitenumbrüchen dargestellt; in einer Tabellenkalkulation wird die Information als Tabelle oder als Grafik dargestellt; und in einem strukturierten Grafikprogramm (z.B. MacDraw) werden die Informationen als Reihen von Grafikobjekten dargestellt.
Was kann ausgewählt werden?
In einer Textverarbeitung betrifft eine Auswahl typischerweise eine Reihe von Zeichen; in einem strukturierten Grafikprogramm ist es eine Reihe von Grafikobjekten.
Welche Befehle können für die getroffene Auswahl aufgerufen werden?
Ein Befehl in einer Textverarbeitung kann darin bestehen, die Schriftart einer Reihe von Zeichen fett zu machen. Ein Befehl in einem strukturierten Grafikprogramm kann darin bestehen, ein Grafikobjekt zu drehen. Figur 1B ist eine Darstellung einer Anzeige gemäß der vorliegenden Erfindung. Ein Befehl wird auf Seite 41 dargestellt, um ein Bild in einer Darstellung nach vorne zu bringen. Eine Darstellung der Grafikinformation ist auf Seite 40 enthalten. Schließlich ist auf Seite 42 eine Auswahl eines bestimmten Grafikobjektes, nämlich eines Kreises, dargestellt.
Ein Entwickler muß dieselben vier Fragen beantworten, die vom Anwender gestellt werden. Glücklicherweise stellt die vorliegende Erfindung Rahmen und Dienstleistungen zur Behandlung dieser vier Fragen zur Verfügung. Die erste Frage, die beantwortet werden muß, lautet: Was modelliere ich? In einem Textverarbeitungsprogramm umfassen die Daten die Zeichen, aus denen sich ein Dokument zusammensetzt. Die Daten in einer Tabellenkalkulation umfassen die Werte und Formeln in den Zellen. In einem Kalenderprogramm umfassen die Daten die Zeiten und Verabredungen zu einem bestimmten Tag. Die Erfindung schafft Vorrichtungen, die dabei helfen, Daten zu modellieren. Es gibt Klassen für die Modellierung bestimmter Datentypen einschließlich: strukturierte Grafiken, Töne und Video. Zusätzlich zu diesen bestimmten Klassen schafft die Erfindung eine Anzahl anderer Abstraktionen, welche die Problemmodellierung unterstützen, einschließlich: Sammelklassen, Mehrfachbenutzungssteuerung, Wiederherstellungsrahmen, und die Programmiersprache C++. Jene Klasse, in der das Datenmodell für einen bestimmten Datentyp eingekapselt ist, schafft ein spezifisches Protokoll für den Zugang zu den Daten, die im Dateneinkapsler enthalten sind, und für die Modellierung derselben, eine Unterstützung zur Außerkraftsetzung eines allgemeinen Protokolls zur Einbettung anderer Dateneinkapsler und zur Einbettung in andere Dateneinkapsler, die Erstellung einer Meldung an alle registrierten Objekte, wenn sich die Daten ändern, und ein Außerkraftsetzen eines allgemeinen Protokolls zur Erstellung von Darstellungen der Daten.
Die nächste Frage, die beantwortet werden muß, lautet: Wie werden die Daten dargestellt? In einem strukturierten Grafikprogramm wird die Reihe an Grafikobjekten typischerweise auf einer Leinwand erzeugt. In einer Tabellenkalkulation handelt es sich typischerweise um eine Tabelle aus Zellen oder um einen Graphen; und in einem Präsentationsprogramm handelt es sich um eine Reihe von Folien oder Gliederungen. Die vorliegende Erfindung schafft eine "Ansicht" der im Dateneinkapsler enthaltenen Daten. Diese Ansicht wird mit Hilfe eines "Ansichtssystems" und mit Grafiksystemaufrufen erzeugt. Als Präsentation von Daten wird jedoch auch das Abspielen von Tönen oder Videoclips angesehen.
Nächste Frage: Was kann ausgewählt werden? In einem Textverarbeitungsprogramm betrifft eine Auswahl eine Reihe von Zeichen; in einem strukturierten Grafikprogramm ist es eine Reihe von Grafikobjekten; und in einer Tabellenkalkulation ist es ein Zellenbereich. Die Erfindung schafft Auswahlklassen für alle grundlegenden Datentypen, welche vom System unterstützt werden. Die abstrakte Basisklasse, welche eine von einem Anwender getroffene Auswahl repräsentiert, schafft eine adreßplatzunabhängige Bestimmung der ausgewählten Daten. Für einen Text wäre dies ein Zahlenbereich von Zeichen anstatt eines Zeigerpaars zu den Zeichen. Dieses Unterscheidungsmerkmal ist wichtig, weil Auswahlen zwischen anderen Maschinen ausgetauscht werden, wenn mit anderen Anwendern (in Echtzeit) zusammengearbeitet wird. Die Basisklasse setzt auch ein allgemeines Protokoll zur Erstellung einer dauerhaften Auswahl entsprechend dieser Auswahl außer Kraft. Dauerhafte Auswahlen sind Unterklassen eines Ankerobjektes und können ein größeres Gewicht aufweisen als ihre entsprechenden flüchtigen Auswahlen, weil dauerhafte Auswahlen Bearbeitungsveränderungen überdauern müssen. So muß sich zum Beispiel eine dauerhafte Textauswahl selbst anpassen, wenn der Text davor oder danach eingefügt wird. Anker werden beim Einfügen von Hypermedia-Verbindungen, Datenflußverbindungen und Anmerkungen verwendet.
Die Basisklasse schafft auch ein allgemeines Außerkraftsetzungsprotokoll zum Aufnehmen, Einbetten und Exportieren von Daten, die in einem Dateneinkapsler enthalten sind. Basisklassen sind unabhängig von der Anwenderschnittstellentechnik, mit deren Hilfe sie erstellt wurden. Auswahlen werden typischerweise über direkte Manipulation durch einen Anwender (z.B. das Aufspüren eines Text- oder Zellenbereiches) erstellt, doch sie können auch über eine Befehlsfolge oder als Ergebnis eines Befehls erstellt werden. Diese Orthogonalität bei der Anwenderschnittstelle ist sehr wichtig. Basisklassen schaffen auch ein bestimmtes Protokoll für den Zugang zum Dateneinkapsler. Es gibt hier eine sehr starke Beziehung zwischen einer bestimmten Unterklasse der Einkapslerklasse und dessen Unterklasse einer Modellauswahlklasse.
Schließlich: Welche Befehle können für die getroffene Auswahl aufgerufen werden? In einem Textverarbeitungsprogramm kann ein Befehl die Schriftart eines ausgewählten Zeichenbereiches verändern, und in einem strukturierten Grafikprogramm kann ein Befehl zum Beispiel ein Grafikobjekt drehen. Die vorliegende Erfindung schafft eine große Anzahl an eingebauten Befehlsobjekten für alle eingebauten Datentypen sowie allgemeine Befehle für Ausschneiden, Kopieren, Einfügen, Hypermedia-Verknüpfungen erstellen, Verknüpfungen vervollständigen, Verbindungen navigieren, Daten auf Verbindungen schieben, Daten auf Verbindungen ziehen, sowie viele Anwenderschnittstellenbefehle. Die abstrakte Basisklasse, welche einen vom Anwender erstellten Befehl repräsentiert, ist verantwortlich für das Erfassen der Semantik einer Anwenderhandlung, für die Bestimmung, ob der Befehl ausgeführt, rückgängig gemacht oder wiederholt werden kann. Befehlsobjekte sind für das Einkapseln aller Informationen verantwortlich, die notwendig sind, um einen Befehl rückgängig zu machen, nachdem ein Befehl ausgeführt wurde. Bevor ein Befehl ausgeführt wird, sind Befehlsobjekte sehr kompakte Darstellungen einer Anwenderhandlung. Die Basisklasse ist unabhängig von der Anwenderschnittstellentechnik, mit deren Hilfe sie erstellt wurde. Befehle werden typischerweise aus Menüs oder über direkte Manipulation durch den Anwender (z.B. durch das Bewegen eines Grafikobjekts) erstellt, aber sie können auch über eine Befehlsfolge erzeugt werden. Diese Orthogonalität bei der Anwenderschnittstelle ist sehr wichtig.
Vorteile von Rahmenwerken
Die Vorteile des Einsteckens der Abstraktionen in der Erfindung sind größer als die Schaffung eines Begriffskonzeptes. Das Einstecken in das Rahmenwerk schafft zahlreiche hochentwickelte Merkmale, die in das Basisbetriebssystem eingebaut sind. Dies bedeutet, daß das Rahmenwerk wichtige Anwendermerkmale durch Aufruf relativ kleiner Verfahren implementiert. Das Ergebnis ist, daß die Investition in das Codieren für das Rahmenwerk auf zahlreiche Merkmale übertragen wird.

Mehrfache Datentypen

Nach Implementierung einer neuen Datenart wird der neue Datentyp ein Teil des Systems. Bestehende Software, die mit Dateneinkapslern zusammenarbeiten kann, kann Ihren neuen Datentyp ohne Veränderung bearbeiten. Dies unterscheidet sich von derzeitigen Computersystemen, wie zum Beispiel dem Macintosh-Computersystem. Ein Sammelbuch-Zusatzprogramm ist zum Beispiel in der Lage, alle Arten von Daten zu speichern, aber es kann nur Daten darstellen, die über eine Text- oder Schnellzeichnungs-Bildkomponente verfügen. Im Gegensatz dazu stellt das Sammelbuch der vorliegenden Erfindung alle Arten von Daten dar, weil es die Daten in Form eines Objektes behandelt. Jeder neu erstellte Datentyp verhält sich genau so wie die vom System zur Verfügung gestellten Datentypen. Darüberhinaus können die Daten im Sammelbuch bearbeitet werden, da ein Objekt ein Standardprotokoll zum Bearbeiten von Daten schafft.
Das Sammelbuch-Beispiel streicht die Vorteile des Dateneinkapslers hervor. Wenn Software so entwickelt wird, daß sie mit Dateneinkapslern zusammenarbeiten kann, ist es möglich, eine Anwendung so zu konstruieren, daß sie auf einfache Art und Weise mit einem neuen Datentyp umgehen kann. Eine neue Anwendung kann die neue Datenart ohne Veränderung anzeigen und bearbeiten.

Rückgängigmachen auf mehreren Ebenen

Die Erfindung ist so konstruiert, daß sie ein Rückgängigmachen auf mehreren Ebenen unterstützt. Das Implementieren dieses Merkmales erfordert jedoch keinen zusätzlichen Aufwand von seiten eines Entwicklers. Das System merkt sich einfach alle erstellten Befehlsobjekte. Solange das entsprechende Befehlsobjekt vorhanden ist, kann ein Anwender eine bestimmte durchgeführte Veränderung an den Daten rückgängig machen. Weil das System darauf achtet, die Befehle zu speichern und zu entscheiden, welche Befehle rückgängig zu machen sind oder zu wiederholen sind, implementiert ein Anwender keine Prozedur zum Rückgängigmachen.
Dokumentenspeichern, Zuverlässigkeit und Versionenerstellung
Ein Abschnitt des Dateneinkapslerprotokolls beschäftigt sich mit dem Ablegen von Daten in einen Strom und der Wiederherstellung der Daten an einer anderen Stelle und/oder zu einer anderen Zeit. Das System verwendet dieses Protokoll, um das Dokumentenspeichern zu implementieren. Standardmäßig werden die Datenobjekte eines Anwenders beim Speichern in eine Datei gelenkt. Wenn das Dokument geöffnet wird, werden die Datenobjekte wiederhergestellt. Das System verwendet ein Datenverwaltungsrahmenwerk, um sicherzustellen, daß sich die auf die Platte geschriebenen Daten in einem konsistenten Zustand befinden. Anwender neigen dazu, eine Datei oftmals abzuspeichern, damit ihre Daten auf der Platte bewahrt bleiben, falls das System abstürzen sollte. Die vorliegende Erfindung benötigt diese Art des Speicherns nicht, da das System alle Befehlsobjekte bewahrt. Der Zustand des Dokumentes kann durch Starten der letzten Festplattenversion des Dokumentes und durch erneutes Abspielen der Befehlsobjekte ab diesem Zeitpunkt rekonstruiert werden. Zum Zwecke der Zuverlässigkeit zeichnet das System automatisch die Befehlsobjekte auf die Festplatte auf, wenn diese auftreten, so daß im Falle eines Systemabsturzes der Anwender nicht mehr als nur den letzten Befehl verlieren würde.
Die Erfindung unterstützt auch die Versionserstellung eines Dokumentes. Ein Anwender kann einen Entwurf vom aktuellen Zustand eines Dokumentes erstellen. Ein Entwurf ist eine unveränderliche "Momentaufnahme" des Dokumentes zu einem bestimmten Zeitpunkt. (Ein Grund, einen Entwurf zu erstellen, wäre zum Beispiel, diesen an andere Anwender weiterzugeben, damit diese den Entwurf kommentieren können.) Das System kümmert sich automatisch um alle Angelegenheiten, die mit der Erstellung eines neuen Entwurfes zusammenhängen.

Zusammenarbeit

Wie bereits oben erwähnt, kann ein Dokument rekonstruiert werden, indem mit einem Zustand des Dokumentes zu einem zurückliegenden Zeitpunkt begonnen und die Reihe der seit diesem Zeitpunkt durchgeführten Befehlsobjekte wieder daran ausgeführt wird. Dieses Merkmal ermöglicht es Anwendern, ihre Arbeit im Falle eines Systemabsturzes wiederherzustellen, und es kann ebenso dafür verwendet werden, Echtzeit- Zusammenarbeit zu unterstützen. Befehlsobjekte arbeiten aufgrund von getroffenen Auswahlen, die adreßplatzunabhängig sind. Daher kann ein Auswahlobjekt über das Netzwerk an einen Mitarbeiter geschickt und auf einer anderen Maschine verwendet werden. Das gleiche gilt für Befehlsobjekte. Ein von einem Mitarbeiter ausgeführter Befehl kann an die anderen gesandt und ebenso auf deren Maschinen ausgeführt werden. Wenn die Mitarbeiter mit identischen Kopien der Daten beginnen, bleiben ihre Kopien "synchronisiert", während sie die Änderungen vornehmen. Eine Auswahl wird mit Hilfe eines Befehlsobjektes getroffen, so daß alle Mitarbeiter über dieselbe aktuelle Auswahl verfügen.
Das System verwendet ein Merkmal, welches als "modellbasierte Verfolgung" bekannt ist, um eine Mausverfolgung an den Maschinen der einzelnen Mitarbeiter durchzuführen. Das zur Handhabung eines Mausklicks erzeugte Verfolgungsobjekt erzeugt eine Reihe von inkrementellen Befehlen und führt diese aus, wenn ein Anwender die Maus bewegt. Diese Befehle werden zu den Mitarbeitern gesandt und bei jedem einzelnen Mitarbeiter ausgeführt. Das Ergebnis ist, daß jeder Mitarbeiter die Verfolgungsrückmeldung sieht, wenn diese auftritt. Das System errichtet auch eine Zusammenarbeitspolitik. Eine Zusammenarbeitspolitik entscheidet, ob Anwender sich gegenseitig abwechseln müssen, wenn sie Daten verändern wollen, oder ob sie die Änderungen nach Belieben durchführen können. Die Erfindung kümmert sich um die Mechanismen der Zusammenarbeit, wodurch diese Verantwortung von einem Anwendungsentwickler abgenommen wird.

Befehlsfolgenerstellung

Wenn ein System so ausgelegt wird, daß es eine Reihe von Befehlsobjekten verarbeiten kann, ist es auch möglich, eine systemweite Befehlsfolgeneinrichtung zu implementieren. Die Folge von Befehlsobjekten entspricht einer Befehlsfolge von lokalen Maßnahmen. Die Befehlsfolgeneinrichtung verfolgt einfach die an einem Dokument angewandten Befehlsobjekte. Die Befehlsfolgeneinrichtung verwendet auch Auswahlobjekte in Befehlsfolgen. Dieses Merkmal ermöglicht eine individuelle Anpassung einer Befehlsfolge durch Verändern der Auswahl, für die die Befehlsfolge gilt. Da Befehlsobjekte ein Protokoll verwenden, um anzuzeigen, ob sie für eine bestimmte Auswahl angewandt werden können, stellt das System sicher, daß die Befehlsfolgenänderungen des Anwenders gültig sind.

Hypermedia-Verknüpfung

Dauerhafte Auswahlen, die auch als Anker bekannt sind, können durch Verknüpfungsobjekte verbunden werden. Ein Verknüpfungsobjekt enthält Hinweise auf die zwei Anker, die seine Endpunkte bilden. Für das System ist die Verknüpfung bidirektional; beide Enden verfügen über gleiche Fähigkeiten. Bestimmte höhere Anwendungen von Verknüpfungen können der Verknüpfung eine Richtung auferlegen. Das Einzelverknüpfungsobjekt unterstützt zwei Standardmerkmale: Navigation und Datenfluß. Ein Anwender kann von einem Ende der Verknüpfung zum anderen navigieren. Normalerweise umfaßt dies das Öffnen des Dokumentes, welches den Bestimmungsanker enthält, und das Markieren der dauerhaften Auswahl. Das exakte Verhalten wird vom Ankerobjekt am Bestimmungsende bestimmt. Zum Beispiel kann eine Verknüpfung mit einer Animation die Animation abspielen. Eine Verknüpfung zu einer Datenbankabfrage kann die Abfrage ausführen.
Verknüpfungen ermöglichen auch den Datenfluß. Die ausgewählten Daten an einem Ende der Verknüpfung können zum anderen Ende übertragen werden, um dort die Auswahl zu ersetzen. In den meisten Fällen ist die Wirkung die gleiche, als würde der Anwender die Auswahl an einem Ende kopieren, die Verknüpfung zum Navigieren hin zum anderen Ende verwenden und dort die Daten einfügen. Das System berücksichtigt alle Details im Zusammenhang mit dem Navigieren von einem Ende einer Verknüpfung zum anderen (z.B. die Positionierung des Bestimmungsdokumentes, das Öffnen dieses Dokumentes, das Weiterblättern des Bestimmungsankers, um es darzustellen, usw.). Auf ähnliche Weise behandelt das System die Details der Übertragung der Daten quer über die Verknüpfung. Letzteres geschieht durch Verwendung des Protokolls der Auswahl, um auf die Daten, auf die es sich bezieht, zuzugreifen und sie zu verändern.

Anmerkungen

Die Erfindung unterstützt eine systemweite Anmerkungseinrichtung. Diese Einrichtung ermöglicht es einem Autor, einen Dokumentenentwurf zur Nachbearbeitung zu verteilen. Die Nachbearbeiter können Anmerkungen am Dokument anbringen, und nach erfolgter Nachbearbeitung das Dokument zum Autor zurückschicken. Der Autor kann danach die angebrachten Anmerkungen überprüfen und entsprechende Maßnahmen setzen. (Ein Autor kann ebenfalls Anmerkungen im Dokument anbringen.) Der Nachbearbeiter muß nicht dieselbe Software verwenden wie der Autor. Stattdessen kann der Nachbearbeiter eine standardmäßige Anmerkungsanwendung verwenden. Diese Anwendung ließt die Daten aus dem Entwurf des Autors und erstellt eine Darstellung der Daten, an der Anmerkungen angebracht werden können. (Die Erstellung einer derartigen Präsentation ist Teil des standardmäßigen Dateneinkapselprotokolls.)
Der Nachbearbeiter kann Auswahlen im Dokument erstellen und Anmerkungen mit der Auswahl verknüpfen. Die Verknüpfung zwischen der Anmerkung und der Auswahl ermöglicht es dem System, die Anmerkung "hinter" die Auswahl, auf die sie sich bezieht, zu stellen. Die Verknüpfungen machen auch die Anmerkungsstruktur deutlich, so daß das System Standardbefehle implementieren kann, um Anmerkungen zu manipulieren. Der Inhalt der angebrachten Anmerkungen kann aus jedem beliebigen Datentyp bestehen, der im System implementiert ist, nicht nur Text oder Grafiken. Der Inhalt einer Anmerkung wird mit Hilfe eines Dateneinkapslers implementiert, und beim Öffnen einer Anmerkung wird eine bearbeitbare Darstellung der Daten geschaffen.

Datendarstellung

Die Datendarstellung hängt mit der Beantwortung der Frage "Welche Daten modelliere ich?" zusammen. Die vorliegende Erfindung schafft Einrichtungen, welche bei der Modellierung von Daten helfen. Es gibt Klassen für das Modellieren bestimmter Datentypen, einschließlich: Text, strukturierte Grafiken, Töne und Video. Zusätzlich zu diesen spezifischen Klassen schafft die Erfindung eine Anzahl anderer Abstraktionen, die helfen, ein Problem zu modellieren: die Sammelklassen, die Mehrfachbenutzungssteuerung, das Wiederherstellungsrahmenwerk, und die Programmiersprache C++ selbst. In der vorliegenden Erfindung handelt es sich bei der Klasse, die das Datenmodell für einen bestimmten Datentyp einkapselt, um eine Unterklasse der Einkapslerklasse.
Die Einkapslerklasse
Ein Entwickler erzeugt einen Behälter für einen bestimmten Typ von Datendarstellung, indem er eine von der Einkapslerklasse abgeleitete Klasse erzeugt. Für jeden Datentyp im System (z.B. Grafikobjekte, formatierten Text, Tabellenkalkulationszellen) muß jeweils eine unterschiedliche abgeleitete Klasse vorhanden sein, die als Behälter für die Daten eines Typs arbeiten. Jede einzelne Einkapslerklasse stellt ein typenspezifisches Protokoll zur Verfügung, um auf die darin enthaltenen Daten zugreifen und sie verändern zu können. Dieses Protokoll wird typischerweise von Präsentationen zur Darstellung von Daten und von Befehlen zur Veränderung von Daten verwendet. Zusätzlich zu einem typenspezifischen Protokoll schafft die Einkapslerklasse ein allgemeines Protokoll, welches das Einbetten von Dateneinkapslern als "Zwischenkästen" in andere fremde Typen unterstützt. Dieses Protokoll muß in die abgeleitete Klasse implementiert werden, um die Erzeugung von Darstellungen, Editoren und Auswahlen für die eingekapselten Daten zu unterstützen. Ein Behälter muß nur dieses allgemeine Protokoll verstehen, um das Einbetten eines beliebigen fremden Datentyps zu verstehen.

Auswahl einer Darstellung für Daten

Der Datentypgestalter kann sowohl aus dem C++-Objektmodell als auch aus einer großen Reihe an Standardklassen für die Gestaltung einer Darstellung für einen bestimmten Datentyp auswählen. Die von der Erfindung zur Verfügung gestellten Klassen sollten stets berücksichtigt werden, bevor einzigartige Klassen zur Darstellung von Daten gestaltet werden. Dies verringert den Aufwand, der beim Erzeugen neuer Klassen notwendig sein kann, welche ähnliche oder identische Funktionen bieten wie solche, die bereits im System vorhanden sind. Die grundlegendste dieser Klassen ist das C++- Objektmodell. Ein Gestalter kann eine Klasse oder Klassen erstellen, die dem geistigen Modell des Anwenders sehr nahe kommen, um die Klassen darzustellen, mit denen der Anwender arbeitet.
Die grundlegenden Klassen der Erfindung bieten viele grundlegende Möglichkeiten, Daten darzustellen. Sammelklassen bieten viele Möglichkeiten, miteinander in Beziehung stehende Objekte im Speicher zu sammeln, angefangen von einfachen Reihen bis hin zu Wörterbüchern. Ebenso sind plattenbasierte Sammlungen verfügbar, die dauerhafte, unbeschädigte Sammlungen von Objekten bieten. Ein Datentyp, der zwei(2D) und dreidimensionale (3D) Grafikmodellierung erfordert, wie zum Beispiel ein grafischer Editor, wird ebenfalls unterstützt. Zahlreiche 2D- und 3D-Modellierobjekte werden gemeinsam mit Transformation, Matrixklassen und 3D- Kameras angeboten. Auf ähnliche Weise schafft die Erfindung einen hochentwickelten Textdatentyp, der vollständigen internationalen Text, ästhetische Typographie und einen erweiterbaren Formatierungsmechanismus unterstützt. Die Erfindung bietet auch Unterstützung für zeitbasierte Medien, wie zum Beispiel Ton und Video. Hochentwickelte Zeitkontrollmechanismen sind verfügbar, um eine Synchronisierung zwischen verschiedenen Arten zeitbasierter Medien zu ermöglichen.

Darstellungsprotokoll

Die Einkapslerklasse bietet ein Protokoll für die Erstellung verschiedener Darstellungsklassen für Daten, die im Einkapsler enthalten sind. Die Darstellungen umfassen eine Daumennagel-Darstellung, eine Nur-Blättern-Darstellung, eine auswählbare Darstellung, und eine bearbeitbare Darstellung. Ebenso gibt es ein Protokoll zur Auswahl von Größen für die Darstellungen und zum Einpassen der Daten in die ausgewählte Größe. Unterklassen der Einkapslerklasse sind verantwortlich für das Außerkraftsetzen und Implementieren dieser Protokolle, um das Einbetten der Daten in andere Einkapsler zu unterstützen. Die Darstellungen umfassen derzeit:
Daumennagel - Diese Darstellungsart soll dem Anwender einen kurzen Blick darauf ermöglichen, was im Einkapsler enthalten ist. Sie ist typischerweise klein und kann die Daten maßstäblich verkleinern und/oder zuschneiden, um die Daten der Größe anzupassen.
Nur-Blättern - Diese Darstellungsart ermöglicht es dem Anwender, die Daten in ihrer normalen Größe zu sehen, aber der Anwender kann die Daten weder auswählen noch verändern.
Auswählbar - Diese Darstellungsart ermöglicht es zusätzlich zu den Möglichkeiten der Nur-Blättern-Darstellungsart, die Daten auszuwählen. Dies wird für Anmerkungen benötigt, um Anmerkungen an Auswahlen in den Daten anhängen zu können, ohne eine Veränderung der Daten selbst zu erlauben. Die auswählbare Darstellungsart wird typischerweise als eine Unterklasse der Nur-Blättern-Betriebsart implementiert.
Bearbeitbar - Diese Darstellungsart ermöglicht es zusätzlich zu den Möglichkeiten der Auswählbar-Darstellungsart, die Daten zu verändern. Dies ist die Darstellungsart, die es dem Anwender ermöglicht, neue Daten zu erzeugen und bestehende Daten zu bearbeiten. Derzeit stellt diese Darstellungsart ihr eigenes Fenster für die Bearbeitung zur Verfügung. Es ist wahrscheinlich, daß in der Zukunft eine Unterstützung für Darstellungen hinzugefügt wird, die es ermöglicht, Bearbeitungen an Ort und Stelle vorzunehmen. Die bearbeitbare Darstellung ist typischerweise als Unterklasse der auswählbaren Darstellung implementiert.

Änderungsmeldungen

Wenn die in einem Einkapsler enthaltenen Daten geändert werden, ist es notwendig, Klienten (z.B. eine Ansicht der Daten) über die Veränderungen zu informieren. Einkapsler stützen sich auf eine eingebaute Klasse für die standardmäßige Unterstützung von Meldungen, damit der Einkapsler Klienten über die an der Datendarstellung vorgenommenen Veränderungen informieren kann. Ein Klient kann eine Verbindung mit einem Einkapsler für die Meldung bezüglich bestimmter Veränderungen oder aller Veränderungen herstellen. Wenn eine Änderung auftritt, fordert der Einkapsler das Modell auf, die Meldung über die Änderung an alle interessierten Klienten weiterzugeben.

Datendarstellung

Dieser Abschnitt beschäftigt sich damit, wie das System Daten für einen Anwender darstellt. Nachdem die Daten für das System dargestellt werden, ist es die Aufgabe der Anwenderschnittstelle, die Daten für einen Anwender auf geeignete und sinnvolle Weise darzustellen. Die Anwenderschnittstelle errichtet einen Dialog zwischen dem Anwender und den Modelldaten. Dieser Dialog ermöglicht es dem Anwender, die Daten zu betrachten oder auf andere Weise aufzunehmen, und gibt dem Anwender die Möglichkeit, die Daten zu verändern oder zu bearbeiten. Dieser Abschnitt beschäftigt sich hauptsächlich mit der Datendarstellung.

Die Anwenderschnittstelle

Ein Entwickler erzeugt eine Klasse, um die Darstellung von Daten zu ermöglichen, um mit dem Dateneinkapsler zu interagieren. Durch Abtrennen des Datenmodells von der Darstellung ermöglicht die Erfindung mehrfache Darstellungen derselben Daten. Einige Anwendungen, wie zum Beispiel der Apple Macintosh Finder, unterstützen bereits eine eingeschränkte Form mehrfacher Darstellungen derselben Daten. Manchmal ist es hilfreich, in der Lage zu sein, unterschiedliche Ansichten derselben Daten zur selben Zeit anzeigen zu lassen. Diese unterschiedlichen Ansichten können zum Beispiel zur selben Klasse gehören - wie zum Beispiel in einem 3D-CAD-Programm, welches vier unterschiedliche Ansichten derselben Daten anzeigt. Für jede Darstellungsart mußte ein Anwender früher eine Ansicht schreiben, die das Modell und eine Reihe von Verfolgern und Verfolgungsbefehlen darstellen kann, welche das Modell auswählen und verändern können.

Feststehende Darstellungen

Die einfachste Darstellungsart ist die Bezeichnung der Daten. Die Bezeichnung ist eine Textkette, welche den Dateninhalt oder den Datentyp anzeigt. Beispiele umfassen "Kapitel 4", Bundesstaatliche Einkommenssteuern 1990", "Zu erledigen". Eine weitere einfache Darstellungsart, ein Bildsymbol, ist eine kleine grafische Darstellung der Daten. Normalerweise zeigt es den Datentyp an. Beispiele dafür sind ein Buch, ein Bericht, ein Finanzmodell, eine Tonoder Videoaufzeichnung, eine Zeichnung. Sie können jedoch auch Zustände anzeigen, wie zum Beispiel einen Drucker, der gerade druckt, oder auf den Inhalt verweisen, wie zum Beispiel eine verkleinerte Ansicht einer Zeichnung. Der Daumennagel schließlich ist eine kleine Ansicht der Modelldaten. Diese Ansicht kann nur einen Ausschnitt der Daten zeigen, um in den verfügbaren Raum zu passen. Beispiele dafür wären eine geschrumpfte Zeichnung, das Inhaltsverzeichnis eines Buches, ein geschrumpfter Brief, oder die geschrumpfte erste Seite eines langen Dokumentes. Eine Nur-Blättern- Darstellung ermöglicht es dem Anwender, die Daten in ihrer normalen Größe zu betrachten, aber der Anwender ist dabei nicht in der Lage, die Daten auszuwählen oder zu verändern.

Auswählbare Darstellungen

Auswählbare Darstellungen ermöglichen es einem Anwender, Informationen aus den Daten zu betrachten, zu erforschen und herauszuziehen. Diese Darstellungsarten bieten zusammenhängende Informationen: worum es sich bei den Daten handelt, wo die Daten sind, wann die Daten erstellt wurden. Es kann hilfreich sein, Daten in einer strukturierten Form darzustellen, wie zum Beispiel als Liste, als Gitter, als Gliederung, oder räumlich aufgeteilt. Ebenso ist es hilfreich, die Beziehungen zwischen den einzelnen Datenelementen, die Beziehung der Daten zu ihren jeweiligen Behältern oder Geschwistern und alle anderen Abhängigkeiten darzustellen.
Auswählbare Darstellungen können auch Metadaten darstellen. Ein Beispiel dafür ist die aktuelle Auswahl, welche die Datenelemente anzeigt, die ein Anwender gerade bearbeitet. Eine andere Art von Metadaten ist eine Hypermedia- Verknüpfung zwischen Datenelementen. Die Ansicht kann auch auf andere Anwender hinweisen, die gemeinsam an den Daten arbeiten.
Auswählbare Darstellungen sind für gewöhnlich sehr datenartspezifisch. Sie bestehen aus Fenstern, Ansichten und anderen Anwenderschnittstellenobjekten, die individuell angepaßt werden können, um den Datentyp am besten wiedergeben zu können. Einige Beispiele dafür sind:
Tonaufzeichnungen - Ein Kontrollfeld würde hörbare Darstellung ermöglichen. Ansichten würden den Ton als musikalische Partitur oder als Wellenformen darstellen. Ansichten können eine Musternummer oder Zeitanzeigen darstellen.
Finanzmodell - Das Modell könnte als Reihe von Formeln und anderen Parametern betrachtet werden. Es könnte Werte aus dem Modell zu einem bestimmten Zeitpunkt oder mit bestimmten Eingabewerten als eine Tabellenkalkulation oder in verschiedenen grafischen Formen anzeigen.
Buch - Das Modell könnte als Inhaltsverzeichnis, als Index, als eine Liste von Abbildungen angesehen werden. Es könnte als eine Reihe von Seiten, eine Reihe von Kapiteln oder als kontinuierlicher Textfluß angesehen werden.
Videoaufzeichnung - Das Modell könnte als eine Reihe von Einzelbildern oder als kontinuierliche Darstellung angesehen werden. Ansichten können Spurmarkierungen, Einzelbildnummer und Zeitangaben umfassen.
Behälter, die andere Objekte enthalten - Die Objekte könnten alphabetisch sortiert nach Namen, Typ oder anderen Attributen, als eine Reihe von Bildsymbolen oder eine Reihe von Daumennägeln angesehen werden.

Bearbeitbare Darstellungen

Bearbeitbare Darstellungen sind ähnlich wie interaktive Darstellungen, außer daß bei ihnen auch eine Veränderung der Daten möglich ist. Sie erreichen dies, indem sie eine direkte Manipulation der Daten mit der Maus oder einem anderen Zeiger erlauben. Ebenso erlauben sie, daß die Daten symbolisch durch Menüpunkte und andere Steuervorrichtungen manipuliert werden.

Datenzugriff

Darstellungen interagieren mit Dateneinkapslern, um die Daten und andere darzustellende Informationen zu bestimmen. Darstellungen fragen das Modell nach den benötigten Informationen ab. Die Darstellung kann die gesamten Daten oder nur Teile davon darstellen, die im Dateneinkapsler enthalten sind oder von darin enthaltenen Daten abgeleitet werden können.

Änderungsmeldung

Da viele gleichzeitige Darstellungen eines einzigen Modells möglich sind, können die Daten von vielen Quellen, einschließlich von Mitarbeitern, geändert werden. Jede Darstellung ist dafür verantwortlich, sich selbst in bezug auf die Modelldaten stets auf dem aktuellen Stand zu halten. Dies wird durch ein Ansuchen um Meldung erreicht, wenn sich das gesamte Modell oder ein Teil davon ändert. Wenn eine Änderung an den Daten vorgenommen wird, an denen die Darstellung interessiert ist, erhält die Darstellung eine Meldung und aktualisiert ihre Ansicht entsprechend. Eine Änderungsmeldung kann auf jede der unten angeführten Arten erzeugt werden. Zum ersten können Änderungsmeldungen vom Verfahren im Dateneinkapsler erzeugt werden, der die Modelldaten gerade ändert. Zum zweiten kann die Änderungsmeldung von jenem Befehl erzeugt werden, der die Änderung verursacht hat. Wie zuvor erwähnt, verfügen diese beiden Ansätze über Vorteile. Die Erzeugung der Meldung aus dem Dateneinkapsler stellt sicher, daß Klienten stets benachrichtigt werden, wenn sich die Daten ändern. Die Erzeugung der Meldung durch den Befehl ermöglicht eine Meldung auf "höherer Ebene" und verringert die Unruhe von Meldungen, die von einer komplizierten Veränderung verursacht werden.

Überblick über das Meldungsrahmenwerk

Das Meldungsrahmenwerk bietet einen Mechanismus zur Verbreitung von Änderungsinformationen zwischen Objekten. Das Rahmenwerk ermöglicht es Objekten, ein Interesse daran zu bekunden und Meldungen über Änderungen in Objekten zu empfangen, von denen sie abhängig sind. Es ist eine Standardschnittstelle für Klassen vorhanden, welche den Klienten Meldungen zur Verfügung stellt. Änderungsklassen bieten Meldungsquellobjekten die Möglichkeit, Listen von Klienten zu verwalten und Meldungen an jene Klienten zu senden. Meldungsobjekte erfordern keine spezielle Kenntnis der Klasse von Objekten, die die Meldungen erhalten. Verbindungsobjekte sorgen für die Lieferung der Meldungen vom Meldungsgeber zu den bestimmten Meldungsempfangsobjekten. Mit diesen Verbindungsobjekten ist eine Spezialisierung bezüglich der Art möglich, wie Meldungen an unterschiedliche Empfängerklassen überliefert werden. Schließlich transportieren Meldungsobjekte beschreibende Informationen bezüglich einer Änderung, und Interessen beschreiben eine bestimmte Meldung von einem Meldungsquellobjekt.

Flußdiagramm der Meldungsverbreitung

Figur 18 ist ein obiekterzeugendes Meldungsflußdiagramm für ein Meldungsquellobjekt. Die Verarbeitung beginnt beim Punkt 1800 und geht sofort zum Funktionsblock 1810 weiter, wo ein Meldungsempfangsobjekt eine Verbindung zu sich selbst herstellt. Danach, bei Funktionsblock 1820, fügt das Meldungsempfangsobjekt geeignete Interessen für eine oder mehrere Meldungen von einem oder mehreren Meldungsquellobjekten hinzu. Diese Interessen werden von dem/den Meldungsquellobjekt/en definiert.
Das Klientenobjekt fordert das Verbindungsobjekt auf, sich mit der/den Meldungsquelle/n für Meldungen zu verbinden, die von den Interessen in der Verbindung im Funktionsblock 1830 festgelegt werden. Danach wird im Funktionsblock 1840 für jedes Interesse an der Verbindung die Verbindung als an der Meldung interessiert am Meldungsgeber angemeldet. Danach nimmt das System beim Funktionsblock 1845 einen Wartezustand ein, bis eine Änderung erkannt wird. Wenn eine Systemänderung auftritt, geht die Steuerung sofort zu 1850 weiter, wo sich ein Meldungsquellobjekt ändert und Aufrufe dessen Meldungsgeber mit einer Meldung benachrichtigen, welche die Änderung beschreibt.
Für jede Verbindung, die als an der Meldung interessiert am Meldungsgeber angemeldet ist, wird die Verbindung bei Funktionsblock 1860 aufgefordert, die Meldung zu verschicken. Bei Funktionsblock 1870 wiederum versendet die Verbindung die Meldung mit dem für den Meldungsempfänger geeigneten Verfahren. Schließlich ergreift der Meldungsempfänger bei Funktionsblock 1880 die für die Meldung erforderliche Maßnahme, und beim Entscheidungsblock 1885 wird eine Prüfung durchgeführt, um zu bestimmen, ob eine weitere Verbindung beim Meldungsgeber als an der Meldung interessiert angemeldet ist. Wenn es eine derartige Verbindung gibt, geht die Steuerung weiter zu 1850. Wenn keine weitere Verbindung zu bedienen ist, geht die Steuerung weiter zum Funktionsblock 1845, um auf die nächste Änderung zu warten.

Datenfestlegung

Die Datenfestlegung betrifft die Auswahl der Datenverarbeitung. Wenn ein Anwender Daten manipulieren muß, die in einer Darstellung enthalten sind, müssen die Daten in der Lage sein, Untergruppen dieser Daten festzulegen. Der Anwender bezeichnet diese Festlegung typischerweise als eine "Auswahl", und das System stellt eine Basisklasse zur Verfügung, von der sich alle Auswahlklassen ableiten. Die Erfindung schafft auch Auswahlklassen für alle grundlegenden Datentypen, die vom System unterstützt werden.

Modellauswahl

Bei dem Objekt, welches die Festlegung einer Untergruppe von Daten in einer Darstellung enthält, handelt es sich um eine Modellauswahlklasse. Im Falle einer Textdarstellung besteht eine mögliche Auswahlfestlegung aus einem Paar von Zeichenverschiebungen. In einem strukturierten Grafikmodell muß jede Form einer einzigartigen Kennung zugeordnet werden, und die Auswahlfestlegung besteht hier aus einer Reihe einzigartiger Kennungen. Keine der Festlegungen verweist direkt auf die Auswahldaten, und sie können an mehrfachen Kopien der Daten angewandt werden.

Zugriff auf festgelegte Daten

Eine Auswahl versteht das Darstellungsprotokoll für den Zugriff auf und die Veränderung von Daten und weiß, wie Daten an einer lokalen Adreßposition zu finden sind. Befehlsobjekte greifen auf die Daten einer Darstellung durch Datenauswahl zu und erfordern daher keine Kenntnis bezüglich der Umwandlung von den festgelegten zu den wirklichen Daten im lokalen Modell. Es ist Aufgabe des Auswahlobjektes, Zugriff auf die wirklichen Daten von der adreßplatzunabhängigen Festlegung zu bieten. In einem Texteinkapsler kann diese Verarbeitung das Abfragen des Einkapslers bezüglich der tatsächlich in einem Bereich enthaltenen Zeichen erfordern. In einem Basismodell wie zum Beispiel einem grafischen Editor enthält die Auswahl typischerweise Stellvertreter für die wirklichen Objekte. Der Einkapsler muß eine Nachschlageeinrichtung zur Umwandlung des Stellvertreters in das wirkliche Objekt zur Verfügung stellen.

Standard-Bearbeitungsprotokoll

Die Modellauswahlklasse schafft ein Protokoll für den Austausch von Daten zwischen Auswahlen. Durch Implementieren des Protokolls für die Typenverhandlung, Absorbieren, Einbetten und Exportieren von Daten unterstützen abgeleitete Klassen die meisten Standard-Bearbeitungsbefehle. Dies bedeutet, daß die vom System zur Verfügung gestellten Bearbeitungsbefehle (Ausschneiden, Kopieren, Einfügen, Daten schieben usw.) für die dargestellte Datenart funktionieren und keine neuerliche Implementierung für jede einzelne Anwendung erforderlich ist. Die Modellauswahlklasse unterstützt auch direkt den Austausch von Ankern und Verknüpfungen, aber sie ist angewiesen auf die Implementierung mehrerer Schlüsselmethoden der abgeleiteten Klasse, um den Austausch der Daten der Darstellung zu unterstützen:
CopyData (Daten kopieren) muß von der abgeleiteten Klasse implementiert werden, um eine Kopie der festgelegten Daten zu exportieren. Die Implementierung schafft einen neuen Dateneinkapsler für den angeforderten Typ und gibt diesen zurück, welcher eine Kopie der festgelegten Daten enthält.
AdoptData (Daten adoptieren) muß von der abgeleiteten Klasse implementiert werden, um das Absorbieren oder Einbetten von Daten in die assoziierte Darstellung der Festlegung zu unterstützen. Wenn die Daten absorbiert werden sollen, müssen sie von einem Typ sein, der direkt in die Darstellung des Empfängers aufgenommen werden kann. Die absorbierten Daten werden der Darstellung entsprechend der Festlegung hinzugefügt. Es ist häufig bei vielen Datentypen der Fall, daß momentan festgelegte Daten durch die jüngst absorbierten Daten ersetzt werden. Alle ersetzten Daten werden in einen Dateneinkapsler zurückgegeben, um die Undo-Funktion (Rückgängigmachen) zu unterstützen. Wenn die Daten eingebettet werden sollen, ist der Einkapsler als ein Zwischenkasten eingebaut und wird als ein Kind der Darstellung hinzugefügt.
ClearData (Daten löschen) muß von der abgeleiteten Klasse implementiert werden, um die festgelegten Daten von der assoziierten Darstellung zu löschen. Ein Einkapsler des nativen Typs der Darstellung, der die gelöschten Daten enthält, muß zurückgegeben werden.

Anwenderschnittstelle

Die Anwenderschnittstelle zur Erzeugung von Festlegungen liegt typischerweise in der Verantwortlichkeit einer Darstellung der Daten. Abhängig von dem Datentyp und dem Darstellungsstil ist eine Anzahl von Mechanismen verfügbar. Die bevorzugteste Anwenderschnittstelle zur Erzeugung einer Auswahl ist direkte Manipulation. In einem einfachen Grafikmodell können Objekte durch direktes Klicken auf das Objekt mit der Maus oder durch Ziehen einer Auswahlbox rund um mehrere Objekte mit einem Mausverfolger ausgewählt werden. In einem Text kann eine Auswahl als Ergebnis eines Suchbefehles erzeugt werden. Eine weitere häufige Art der Erzeugung von Auswahlen ist das Ergebnis eines Menübefehles, wie zum Beispielen "Suchen". Nachdem der Befehl gegeben wurde, wird das Dokument bis zur geeigneten Stelle weitergeblättert, und der gesuchte Text wird ausgewählt.
Schließlich können Auswahlen durch eine Befehlsfolge erzeugt (oder programmatisch erzeugt) werden, und das Ergebnis wäre hier das gleiche, als wenn ein Anwender die Auswahl direkt erzeugen würde. Die "Benennung" von Auswahlen für Befehlsfolgen umfaßt die Erstellung einer Sprache zum Beschreiben der Auswahl. In einem Text könnte eine Auswahl zum Beispiel "das zweite Wort des vierten Absatzes auf Seite zwei" sein. Die Architektur der Erfindung unterstützt auch Befehlsfolgen.

Datenveränderung

Datenveränderungen betreffen die Frage: Welche Befehle können für die getroffene Auswahl aufgerufen werden? Wenn ein Anwender die in einer Darstellung enthaltenen Daten verändern will, muß das System in der Lage sein, exakt den Typ der durchzuführenden Veränderung festzulegen. In einem Textverarbeitungsprogramm zum Beispiel könnte ein Anwender das Schriftbild eines ausgewählten Zeichenbereiches verändern wollen. Oder in einem strukturierten Grafikprogramm könnte ein Anwender ein Grafikobjekt drehen wollen. Alle Anwendermaßnahmen, welche die in einem Dateneinkapsler enthaltenen Daten verändern, werden durch "Befehlsobjekte" dargestellt.

Das Modellbefehlsobjekt

Die abstrakte Basisklasse, welche einen vom Anwender erzeugten Befehl darstellt, ist das Modellbefehlsobjekt. Unterklassen des Modellbefehlsobjektes erfassen die Semantik der Anwendermaßnahmen, wie zum Beispiel: kann ausgeführt, rückgängig gemacht, und wiederholt werden. Diese Unterklassen sind unabhängig von der Anwenderschnittstellentechnik, mit deren Hilfe sie erstellt wurden. Im Gegensatz zu Macapp werden Geräteereignisse vom System in Befehlsobjekte übersetzt, sobald die Semantik einer Anwendermaßnahme bekannt ist.
HandleDo, HandleUndo, und HandleRedo (BearbeitungDurchführen, BearbeitungRückgängigmachen, und Bearbeitungwiederholen)
Die Erzeugung einer neuen Befehlsklasse umfaßt das Außerkraftsetzen einer Anzahl von Methoden. Die drei wichtigsten Methoden zum Außerkraftsetzen sind: HandleDo (Bearbeitung- Durchführen), HandleUndo (BearbeitungRückgängigmachen), und HandleRedo (BearbeitungWiederholen). Das HandleDo-Verfahren ist verantwortlich für das Ändern des Dateneinkapslers entsprechend der Befehlsart, der er entspricht, und die Auswahl des daran angewandten Befehls. Wenn zum Beispiel der Befehl eine Schriftbildänderung umfaßt, um einen Bereich von Zeichen in einer Textverarbeitung zu ändern, würde das HandleDo-Verfahren ein Verfahren (oder eine Reihe von Verfahren) im Dateneinkapsler aufrufen, um einen zu ändernden Zeichenbereich und ein zu änderndes Schriftbild festzulegen. Eine schwierigere Aufgabe des Handledo-Verfahrens ist das Speichern der Informationen, die notwendig sind, um diesen Befehl später "rückgängig" zu machen. Im Beispiel der Schriftbildänderung umfaßt das Speichern der Informationen zum Rückgängigmachen das Aufzeichnen des alten Schriftbildes des Zeichenbereiches. Die Informationen zum Rückgängigmachen sind für die meisten Befehle sehr einfach abzuspeichern. Einige Befehle jedoch, wie Finden und Ändern, können die Aufzeichnung einer großen Menge an Informationen erfordern, um den Befehl zu einem späteren Zeitpunkt rückgängig machen zu können. Schließlich ist das HandleDo-Verfahren zur Ausgabe einer Änderungsmeldung verantwortlich, welche die am Dateneinkapsler durchgeführten Änderungen beschreibt.
Das HandleUndo-Verfahren ist verantwortlich für das Zurücksetzen eines Dokumentes in den Zustand, den es vor der "Ausführung" des Befehles aufwies. Die anzuwendenden Schritte sind analog zu den Schritten, die im HandleDo- Verfahren oben beschrieben wurden. Das HandleRedo-Verfahren ist verantwortlich für das "Wiederholen" des Befehls, nachdem er ausgeführt und rückgängig gemacht wurde. Anwender schalten oft zwischen zwei Zuständen eines Dokumentes hin und her, um ein Ergebnis eines Befehles mit Hilfe der Undo/Redo-Kombination zu vergleichen. Typischerweise ist das HandleRedo-Verfahren sehr ähnlich dem HandleDo-Verfahren, außer daß beim Redo-Verfahren die Informationen, die zuletzt abgeleitet wurden, wiederverwendet werden können, wenn dieser Befehl ausgeführt wird (die Informationen müssen nicht neu berechnet werden, da sie garantiert gleich sind).

Anwenderschnittstelle

Befehlsobjekte erfassen die Semantik einer Anwenderhandlung. Tatsächlich stellt ein Befehl eine "Arbeitsanforderung" dar, die meistens von einem Anwender erzeugt wird (mit Hilfe unterschiedlicher Anwenderschnittstellentechniken), welche jedoch auch auf andere Art und Weise erzeugt (und angewandt) werden könnte. Das wichtige Konzept dabei besteht darin, daß Befehlsobjekte die einzige Vorrichtung zur Veränderung von Daten, die in einem Dateneinkapsler enthalten sind, darstellen. Alle Veränderungen am Dateneinkapsler müssen durch ein Befehlsobjekt verarbeitet werden, wenn die Vorteile des unendlichen Undo (Rückgängigmachens), das Save-less-Modell (Speichernweniger-Modell) und andere Merkmale der Erfindung verwirklicht werden sollen.
Die bevorzugteste Anwenderschnittstelle zur Ausgabe von Befehlen umfaßt eine Art direkter Manipulation. Ein Objekt, das für die Übersetzung von Geräteereignissen in Befehle und für das "Antreiben" des Anwenderrückmeldeprozesses verantwortlich ist, ist als ein Verfolger bekannt. Die Erfindung bietet eine umfangreiche Reihe an "Verfolgungsbefehlen" zum Manipulieren der eingebauten Datentypen. Zum Beispiel gibt es Verfolgungsbefehle zum Drehen, Skalieren und Bewegen aller 2D-Objekte in Pink, wie zum Beispiel Gerade, Kurven, Polygone usw.
Eine allgemeine Anwenderschnittstelle zur Ausgabe von Befehlen erfolgt über Kontrollen oder das Menüsystem. Menüs werden erstellt, und eine Reihe von damit zusammenhängenden Befehlen wird dem Menü hinzugefügt. Wenn der Anwender einen Punkt im Menü auswählt, wird der entsprechende Befehl "geklont", und das Do-Verfahren (Ausführen-Verfahren) des Befehls wird aufgerufen. Der Programmierer muß sich nie mehr mit Geräteereignissen auseinandersetzen. Weil darüberhinaus die Befehle wissen, an welchen Arten von Auswahlen sie angewandt werden können, werden Menüpunkte automatisch halbhell dargestellt, wenn sie nicht zutreffend sind.
Schließlich können Befehle von einer Befehlsfolge ausgegeben (oder programmatisch erstellt) werden, und die Ergebnisse wären dieselben, als wenn ein Anwender den Befehl direkt ausgeben würde. Die Pink-Architektur unterstützt die Befehlsfolgen; derzeit jedoch ist noch keine Anwenderschnittstelle zur Erzeugung dieser Befehlsfolgen verfügbar.

Eingebaute Befehle

Die Erfindung bietet eine große Anzahl an eingebauten Befehlsobjekten für alle eingebauten Datentypen, und ebenso bietet sie allgemeine Befehle für das Ausschneiden, Kopieren, Einfügen, Starten von Hypermedia-Verknüpfungen, Vervollständigen von Verknüpfungen, Navigieren von Verknüpfungen, Schieben von Daten auf Verknüpfungen, Ziehen von Daten auf Verknüpfungen, sowie viele Anwenderschnittstellenbefehle. Einer der Vorteile der Verwendung von Rahmen besteht darin, daß diese eingebauten Befehlsobjekte mit jedem Dateineinkapsler verwendet werden können.

Weitere Merkmale

Die vorangegangenen Abschnitte dieses Dokumentes konzentrieren sich auf die grundlegenden Merkmale der Erfindung. Es gibt viele zusätzliche Einrichtungen in der Erfindung, welche moderne Merkmale implementieren. Im besonderen umfassen diese Merkmale: modellbasierte Verfolgung, Ablegen, Anker, und Zusammenarbeit.

Modellbasierte Verfolgung

Die Verfolgung ist das Herz einer Anwenderschnittstelle mit Direktmanipulation. Die Verfolgung ermöglicht es den Anwendern, Textbereiche auszuwählen, Objekte zu ziehen, die Größe von Objekten zu verändern, und Objekte zu skizzieren. Die Erfindung erweitert die Verfolgung, so daß sie an mehreren Ansichten und auf mehreren Maschinen funktioniert, indem das Modell tatsächlich verändert wird. Der Verfolger gibt Befehle an das Modell aus, welches Änderungsmeldungen an alle interessierten Ansichten ausgibt.
Die modellbasierte Verfolgung ist die beste Lösung für die Verfolgung in Dokumenten, aber sie hat folgende Nachteile:
(1) die Ansichten des Modells müssen optimiert werden, um eine rasche Reaktion auf Änderungsereignisse zu bieten, und
(2) das Modell muß in der Lage sein, die Zwischen-Verfolgungszustände auszudrücken.

Anker

Dauerhafte Auswahlen oder "Anker" sind Auswahlen insofern sehr ähnlich, als daß sie Festlegungen von Daten in einer Darstellung sind. Der Unterschied besteht darin, daß Anker Bearbeitungsänderungen überstehen müssen, da Anker ihrer Definition nach über Änderungen der Daten hinweg bestehen. Die früher im Dokument beschriebene Implementierung von Grafikauswahlen ist dauerhaft. Die Implementierung von Textauswahlen ist dies jedoch nicht. Wenn ein Anwender Text vor einer Auswahl einfügt oder löscht, müssen die Zeichenverschiebungen angepaßt werden. Es gibt eine Reihe von Ansätzen zum Implementieren von Textankern. Zum ersten behält die Textdarstellung eine Sammlung von Markierungen bei, welche in den Text verweisen, ähnlich wie die Art und Weise, mit der Schriftbilder beibehalten werden. Die Anker umfassen eine einzigartige Kennung, die auf eine Markierung verweist. Wenn der Text geändert wird, werden die entsprechenden Markierungen aktualisiert, aber die Anker bleiben unverändert. Ein weiterer Ansatz besteht darin, eine Bearbeitungsgeschichte für den Text aufzubewahren. Der Anker könnte ein Paar Zeichenpositionen sowie einen Zeitstempel enthalten. Jedes Mal, wenn der Text bearbeitet wird, würde die Geschichte aktualisiert werden, um die Änderung aufzuzeichnen (z.B. 5 Zeichen zur Zeit T von der Position X gelöscht). Wenn der Anker verwendet wird, müßte das System seine Zeichenpositionen aufgrund der Bearbeitungsänderungen, die seit der letzten Verwendung durchgeführt wurden, korrigieren. Zu geeigneten Zeiten können die Geschichte verdichtet und die Anker dauerhaft aktualisiert werden.
Das System bietet durch die Anker-Eigenschaft "gratis" eine große Anzahl an Merkmalen. Alle HyperMedia-Befehle (CreateLink, PushData, PullData, und Follow) verwenden Anker in ihrer Implementierung. Die Implementierung der systemweiten Anmerkungseinrichtung verwendet Anker für deren Implementierung. Der Basisdateneinkapsler bietet Dienste zur Verfolgung von Ankern und Verknüpfungen. Der Anwender ist jedoch dafür verantwortlich, Anker über Darstellungen für den Anwender sichtbar zu machen. Die Anwendung muß auch das entsprechende Befehlsobjekt ausgeben, wenn ein Anwender einen Anker auswählt. Nachdem eine Anwenderschnittstelle für Anker und Verknüpfungen festgenagelt wurde, bietet das Dokumentenrahmenwerk zusätzliche Unterstützung zur Vereinfachung der Verarbeitung.

Ablegen

Das Ablegen ist der Vorgang des Speicherns und Wiederherstellens der Daten auf und von einem dauerhaften Speicher. Alles, was ein Anwender tun muß, damit das Ablegen funktioniert, ist das Implementieren von Strömungsoperatoren für einen Dateneinkapsler. Das standardmäßige Ablegen der Erfindung ist "Bild"-basiert. Wenn ein Anwender ein Dokument öffnet, wird der gesamte Inhalt des Dokumentes in den Speicher eingelesen. Wenn ein Anwender ein Dokument schließt, wird der gesamte Inhalt des Dokuments zurück auf die Platte geschrieben. Dieser Ansatz wurde ausgewählt, weil er einfach, flexibel und leicht zu verstehen ist. Um Daten in einem anderen Format zu speichern, damit zum Beispiel die Kompatibilität mit einem zuvor existierenden Standard- Dateiformat gewährleistet bleibt, sind zwei Ansätze möglich. Zuerst kann eine Einkapslerklasse einen Hinweis auf die tatsächlichen Daten strömen, dann den Hinweis verwenden, um die tatsächlichen Daten zu finden, oder es kann eine neue Unterklasse definiert werden, um eine Datei- Unterklasse zu erzeugen und zurückzugeben.
Der Vorteil des ersten Ansatzes liegt darin, daß der Dateneinkapsler in andere Dokumente eingekapselt werden kann. Der Vorteil des zweiten Ansatzes liegt in der völligen Freiheit, die erzielt wird, um ein bestehendes Datenformat für das gesamte Dokument exakt anzupassen.

Zusammenarbeit

Gleichzeitige Netzwerkzusammenarbeit bedeutet, daß zwei oder mehrere Leute dasselbe Dokument zur selben Zeit bearbeiten. Das System errichtet auch die Zusammenarbeitspolitik; das heißt, ob Anwender sich beim Ändern der Daten abwechseln müssen, oder ob sie frei Veränderungen durchführen können. Ein Entwickler muß sich nicht um die Mechanismen der Zusammenarbeit oder um die Zusammenarbeitspolitik kümmern.

Unterstützung von Zusammenarbeitsauswahlarten

Um die Verwirrung zu verringern und die Modellauswahl zu vergrößern, bietet die Dokumentarchitektur eine Zusammenarbeitsklasse, welche Informationen über die Initialen der Mitarbeiter und das bevorzugte Markierungsbündel enthält.

Unterstützung mehrfacher Auswahlen

Um mehrfache Auswahlen zu unterstützen, muß ein Anwender die Darstellungsansichten verändern, weil jeder Mitarbeiter über eine Auswahl verfügt. Wenn sich die Auswahl des aktiven Mitarbeiters verändert, wird die Standard-Änderungsmeldung gesendet. Wenn sich die Auswahl eines passiven Mitarbeiters ändert, wird ein anderes Meldungsereignis gesendet. Eine Ansicht sollte sich für beide Ereignisse anmelden. Da die Maßnahme auf beide Ereignisse normalerweise dieselbe ist, kann zum Zwecke der Wirtschaftlichkeit dasselbe Handhabungsverfahren für beide Ereignisse angemeldet werden.

Anwenderschnittstelle gemäß der Erfindung

Dieser Abschnitt der Erfindung konzentriert sich in erster Linie auf die erfinderischen Aspekte bei der Erstellung der Anwenderschnittstelle auf der Basis des zuvor diskutierten Betriebssystemrahmens. Der erste Aspekt der Anwenderschnittstelle ist ein Mechanismus, der es einem Anwender ermöglicht, Interaktionen mit verschiedenen Objekten oder Daten, die als Kontrollen bezeichnet werden, zu verwalten.

Kontrolle

Das Objekt, mit dem der Anwender interagiert, um andere Objekte oder Daten zu manipulieren, wird als Kontrolle bezeichnet. Kontrollen verwenden einen Befehl, um den aktuellen Zustand des Objektes oder der Daten zu bestimmen. Nach entsprechenden Interaktionen mit dem Anwender aktualisiert die Kontrolle die Parameter des Befehls und löst seine Ausführung aus. Beispielkontrollen sind Menüs, Auswahlfelder und Radioknöpfe.
Kontrollen verwenden einen Befehl, um den aktuellen Zustand des Objektes oder der Daten zu bestimmen. Nach geeigneten Interaktionen mit dem Anwender aktualisiert die Kontrolle die Parameter des Befehls und löst seine Ausführung aus. Ein Auswahlfeld setzt zum Beispiel einen Befehlsparameter auf Ein oder Aus und führt dann den Befehl aus, um einen Datenwert zu ändern.
Viele Kontrollen zeigen den aktuellen Wert der Daten an, die sie manipulieren. Zum Beispiel zeigt ein Auswahlfeld eine Auswahl nur an, wenn ein Boolscher Datenwert TRUE (WAHR) ist. Wenn sich die Daten ändern, wird das Erscheinungsbild der Kontrolle mit Hilfe eines hier beschriebenen Meldungssystems am aktuellen Stand gehalten. Der Vorgang ist ähnlich wie dem Vorgang, der zum Aktivieren/Deaktivieren von Menüpunkten verwendet wird.
Wenn eine Kontrolle erzeugt wird, muß ein Befehl festgelegt werden. Die Kontrolle erzeugt eine Kopie dieses Befehles und speichert sie im Feld fCommand. Wenn der Befehl Datenwerte zuführt, muß auch ein Zeiger für geeignete Get- (Holen-) und Set- (Einstellen-) Verfahren der Befehle festgelegt werden. Die Kontrollen speichern diese Verfahrenszeiger in den Feldern fGetMethod bzw. fSetMethod. Danach stellt die Kontrolle eine Verbindung für Meldungen her, die anzeigen, daß ihr Datenwert außerhalb veraltet sein kann. Jeder Befehl bietet für diesen Zweck ein Verfahren, das als ConnectData (DatenVerbinden) bezeichnet wird.
Jede Kontrolle enthält ein Verbindungsobjekt, das fDataConnecting genannt wird und das Objekt und das Verfahren zum Empfangen der Meldung anzeigt. Dieses Verbindungsobjekt wurde als ein Argument zum Befehl weitergeleitet. Das Befehlsobjekt ruft das Verbindungsverfahren des Verbindungsobjektes auf, um jeden Meldungsgeber und jedes Interesse hinzuzufügen, das seinen Datenwert beeinflussen könnte. Nach Abschluß ruft die Kontrolle das Verbindungsverfahren des Verbindungsobjektes auf, um die in Figur 3 dargestellten Verbindungen zu errichten. Die Kontrolle aktualisiert ihren Datenwert von ihrem Befehl. Dies erfolgt durch Aufruf des Get-Verfahrens des Befehls (fCommand T (*fGetMethod) ()) . Die Kontrolle speichert diesen Wert in einem geeigneten Feld (z.B. ein Auswahlfeld speichert ihn in einem Boolschen Feld mit der Bezeichnung fChecked), wie dies in Figur 5 dargestellt ist. Danach aktualisiert die Kontrolle ihr Erscheinungsbild. Sie führt diese Maßnahme durch, indem sie das Invalidierungsverfahren des Ansichtssystems aufruft, wodurch angezeigt wird, welcher Abschnitt des Bildschirms aktualisiert werden muß.
Schließlich werden die Datenänderungen und die Meldung gesendet. An irgendeinem Punkt wird ein Befehl ausgeführt, der den Wert der Daten, der von der Kontrolle reflektiert wird, ändert. Dieser Befehl könnte von einer Kontrolle, einem Menüpunkt oder durch direkte Manipulation ausgeführt werden. Die Kontrolle empfängt die Meldung, wie dies in Figur 4 dargestellt wird, und die Kontrolle wird weitergegeben, um die nächste Anwenderauswahl zu erwarten.

Kontrollfeld

Eine Sammlung von Kontrollen wird als Kontrollfeld bezeichnet. Die Kontrollen in einem Kontrollfeld bearbeiten typischerweise tatsächliche Daten (dies ist die Standardeinstellung, aber nicht unbedingt erforderlich). Ihre Maßnahmen sind für gewöhnlich unmittelbar und unabhängig voneinander. Kontrollfelder verwalten den Fortgang des Eingabefokus unter den Kontrollen nach Bedarf. Es ist wahrscheinlich, daß Kontrollfelder von allen Anwenderschnittstellen im System gemeinsam benutzt werden.

Dialogbox

Eine andere Sammlung von Kontrollen wird als Dialogbox bezeichnet. Die Kontrollen in einer Dialogbox bearbeiten typischerweise prototypische Daten (dies ist die Standardeinstellung, aber nicht unbedingt erforderlich). Ihre Maßnahmen werden für gewöhnlich in einer Gruppe zusammengesammelt und danach zusammen ausgeführt, wenn der Anwender auf den Anwenden-Knopf drückt. Dialogboxen verwalten den Fortgang des Eingangsfokus zwischen ihren Kontrollen nach Bedarf.

Eine Kontrolle bei der Ausführung

Wir möchten nun gerne ein Theaterstück in drei Akten präsentieren, um eine Kontrolle bei der Ausführung darzustellen. Figur 2 zeigt die verschiedenen Kontrollen. Ein Theaterstück hilft dabei, eine Kontrolle (in diesem Fall ein Auswahlfeld), einen Befehl, eine Auswahl und einen Dateneinkapsler im Zuge einer Analogie darzustellen.
Auswahlfeld 200 Die Rolle des Auswahlfeldes ist es, einen Boolschen Wert darzustellen, der im Dateneinkapsler gespeichert ist, und seine Änderung zu ermöglichen. Der Wert wird durch das Vorhandensein oder Nichtvorhandensein eines Prüfhakens dargestellt.
Befehl 210 Die Rolle des Befehls ist es, den Wert vom Dateneinkapsler zu erhalten und auf Anweisung vom Auswahlfeld zu ändern.
Auswahl 220 Die Rolle der Auswahl besteht darin, eine Schnittstelle zwischen dem Befehl und den Daten darzustellen.
Daten 230 Die Daten stellen das Ziel der Maßnahmen dar.

Miteinander bekanntmachen

Jeder lernt den anderen ein bißchen besser kennen, wie dies in Figur 3 dargestellt ist. Der Befehl 310 sagt dem Auswahlfeld 300, welche Meldungen die Daten senden können, an denen die Kontrolle sicherlich interessiert ist (woher der Befehl 310 das weiß, geht niemand anderen etwas an). Das Auswahlfeld 300 wiederum verbindet die Daten 320 für die Meldungen.
Unbemerkt von allen anderen hat der Direktor dem Auswahlfeld 300 mitgeteilt, wie es am besten mit dem Befehl 310 interagieren kann. Insbesondere hat er ihm Informationen über das Get-Value-Verfahren ("Hole-Wert-Verfahren") und das Set-Value-Verfahren ("Setze-Wert-Verfahren") des Befehls mitgeteilt. Das Auswahlfeld wird diese Informationen ein wenig später nutzen.

Daten reflektieren

Etwas geschieht mit den Daten - sie senden Meldungen, wie sie in Figur 4 dargestellt sind. Das Auswahlfeld 400 hört von denen, an denen es sein Interesse zum Ausdruck gebracht hat. In Figur 4 drückt die Meldung von den Daten aus, daß die Information, die durch ein X im Auswahlfeld reflektiert wird, fett gemacht werden soll.
Das Auswahlfeld 510 hat eine Meldung von den Daten empfangen, und die Verarbeitung zur richtigen Darstellung des Auswahlfeldes 510 wird in Figur 5 dargestellt. Dies geschieht durch Verwendung des "Hole-Wert-Verfahrens" des Befehls, das es zufällig schon kennt. Bevor er noch dem Auswahlfeld 510 mitteilt, was der richtige Wert ist, geht der Befehl 520 durch die Auswahl durch zu den Daten, um sicherzustellen, daß er wirklich den richtigen Wert kennt. Das Auswahlfeld 510 aktualisiert sich selbst je nach Bedarf.

Daten ändern

Nun betritt der Anwender die Szene und verleiht dem Auswahlfeld 600 einen Haken, wie er in Figur 6 dargestellt ist. Das Auswahlfeld 600 verwendet das Set-Value-Verfahren ("Setze-Wert-Verfahren") des Befehls 610, um den Wert der Daten 620 durch die Auswahl zu setzen. Der gesamte Vorgang wird in Figur 7 dargestellt.

Ein Kontrollfeld bei der Ausführung

Ein Kontrollfeld ist nichts anderes als ein einfaches Fenster, das eine Reihe von Kontrollen enthält, wie sie in Figur 8 dargestellt sind. Diese Kontrollen enthalten einen Befehl, der aufgrund der aktuellen Auswahl betätigt wird. Die Kontrolle wird aktiviert, wenn der Befehl aktiv ist. Nach geeigneter Interaktion mit dem Anwender führt die Kontrolle den Befehl aus und verursacht somit eine Änderung der Daten.

Ein Ton-Kontrollfeld

Als Beispiel für ein Kontrollfeld kann das in Figur 8 dargestellte Ton-Kontrollfeld betrachtet werden. Dieses Kontrollfeld enthält vier Knöpfe 800, 802, 804 und 806 für die Kontrolle des Tonabspielens. Jeder Knopffunktioniert so, wie dies oben im Abschnitt "Ein Kontrollfeld bei der Ausführung" beschrieben wurde.
Play 800 (Abspielen) Diese Kontrolle enthält einen TPlay-Befehl (TSpiel-Befehl). Dieser Befehl ist nur unter bestimmten Bedingungen aktiv, wodurch die Kontrolle nur unter eben jenen Bedingungen aktiviert wird. Zuerst muß ein Ton im geeigneten Dateneinkapsler aktiviert werden. Danach darf der Ton noch nicht abgespielt werden. Schließlich muß sich die Tonposition irgendwo vor dem Ende befinden. Beim Drücken des Knopfes 'Spielen' führt dieser den TPlay-Befehl aus, wodurch der ausgewählte Ton aus dem Lautsprecher hörbar wird.
Step 802 (Schritt) Diese Kontrolle enthält ebenfalls einen TPlay-Befehl (TSpiel-Befehl). Wie dies möglich ist, fragen Sie sich? Nun, da ich das ganze erfinde, können wir vorgeben, daß der TPlay-Befehl einen Parameter enthält, der angibt, wie lange er spielen soll. Für den Step-Knopf ist dies auf ein einziges Muster eingestellt. Der Step-Knopf wird unter denselben Bedingungen aktiviert, wie sie zuvor für den Play-Knopf beschrieben wurden. Wenn er gedrückt wird, führt der Step-Knopf den TPlay-Befehl aus, wodurch der ausgewählte Ton aus dem Lautsprecher erklingt.
Stop 804 (Stopp) Diese Kontrolle enthält einen TStop- Befehl (Tstopp-Befehl). Der Stop-Knopf wird nur dann aktiviert, wenn der ausgewählte Ton gerade abgespielt wird. Wenn er gedrückt wird, führt der Stop-Knopf den TStop- Befehl aus, wodurch der ausgewählte Ton zu spielen aufhört und die aktuelle Tonposition auf den Anfang zurückgesetzt wird.
Pause 806 Diese Kontrolle enthält ebenfalls einen TStop-Befehl. Im Gegensatz zum Stop-Knopf wird dieser TStop-Befehl angewiesen, den Ton nicht zum Anfang zurückzuspulen. Durch Drücken der Play- oder Step-Taste wird die Tonwiedergabe dort fortgesetzt, wo sie angehalten wurde.

Eine Dialogbox bei der Ausführung

Eine Dialogbox ist ähnlich wie ein Kontrollfeld, da es ebenfalls ein einfaches Fenster ist, das eine Reihe von Kontrollen enthält. Hier arbeiten die Kontrollen jedoch nicht an den ausgewählten Daten, sondern an Parametern eines anderen Befehls. Erst wenn der Anwenden-Knopf gedrückt wird, werden die wirklichen Daten geändert.

Ein Farbeditor

Als ein Beispiel für eine Dialogbox kann der in Figur 9 dargestellte Farbeditor betrachtet werden. Er enthält drei Schieberegler, einen für die rote 900, die blaue 910 und die grüne 920 Farbkomponente. Nach dem Einstellen der Schieberegler auf die gewünschten Werte drückt der Anwender auf Anwenden 930, um die Farbe der Auswahl zu ändern.
Rot 900, Grün 910, Blau 920 Für den Anwender sind diese Schieberegler bis auf ihre Beschriftung identisch. So wie bei allen Schiebereglern enthält jeder Schieberegler einen Befehl, der nach einer Anwenderinteraktion ausgeführt wird. Im Gegensatz zu vielen Kontrollen, besonders jenen innerhalb eines Kontrollfeldes, die sofortige Auswirkungen auf die ausgewählten Daten haben, wird vom Befehl, der in diesen Schiebereglern enthalten ist, der Wert eines Parameters eines anderen Befehls dargestellt und verändert. In diesem Fall ist es entweder der rote, der grüne oder der blaue Parameter des im Anwenden-Knopf enthaltenen Befehles.
Anwenden 930 Der Anwenden-Knopf enthält einen TSetColor- Befehl (TSetzeFarbe), der die Farbe der Auswahl bei der Ausführung verändert. Es verfügt über drei Parameter: je einen für die rote, die grüne und die blaue Farbkomponente. Diese Parameter werden von den Schiebereglern angezeigt und als Reaktion auf die Anwenderschnittstelle eingestellt. Wenn der Anwenden-Knopf gedrückt wird, wird dieser Befehl ausgeführt, und die neue Farbe wird eingestellt. Die internen Maßnahmen, welche das Farbbearbeitungsbeispiel begleiten, werden in Figur 10 dargestellt. Die Schieberegler Rot 1000, Grün 1010 und Blau 1020 enthalten einen TFloatControl-Befehl. Diese Befehle enthalten einen einzigen Fließkommawert, den die Kontrolle darstellt. Wenn der Anwender den Schieberegler einstellt, aktualisiert dieser diesen Wert und führt den Befehl aus.
Die Auswahl für den TFloatControl-Befehl legt den TSetColor-Befehl innerhalb des Anwenden-Knopfes 1040 fest. Einer seiner Parameter wird eingestellt, wenn jeder TfloatControl-Befehl ausgeführt. Schließlich wird, wenn der Anwender den Anwenden-Knopf 1040 drückt, der TSetColor-Befehl ausgeführt, und die ausgewählte Farbe 1050 wird geändert.

Klassen

Der folgende Abschnitt beschreibt die Klassen der Kontrollen und Dialogbereiche und ihre primären Verfahren.

Kontrolle

Eine Kontrolle ist die Anwenderschnittstelle für einen oder mehrere Befehle. Die Kontrolle stellt Informationen bezüglich eines Befehls, wie zum Beispiel dessen Namen, dar, und ob er im aktuellen Kontext aktiv ist oder nicht. Nach geeigneter Anwenderinteraktion läßt die Kontrolle einen Befehl ausführen. Falls zutreffend, erlangt die Kontrolle den aktuellen Wert der Daten, die der Befehl ändert, und zeigt ihn dem Anwender an. Sie kann einen Befehlsparameter einstellen, der einen neuen Wert dieser Daten anzeigt, bevor der Befehl ausgeführt wird.
Verfahren zur Erzeugung einer Auswahl an der Kontrolle, mit zusätzlicher Festlegung eines Befehls innerhalb der Kontrolle als Option. Der Nachschlage-Befehl ist eine rein virtuelle Funktion, um Unterklassen die Flexibilität zu geben, in wievielen Befehlen sie enthalten sind und wie sie gespeichert werden.
Verfahren, die aufgerufen werden, wenn die Darstellung geöffnet und geschlossen wird. Wenn die Darstellung geöffnet wird, stellt die Kontrolle eine Verbindung für Meldungen her, die ihren Zustand beeinflussen können. Wenn die Darstellung geschlossen wird, werden diese Verbindungen abgebrochen.
Verfahren, die aufgerufen werden, wenn die Darstellung aktiviert und deaktiviert wird. Wenn die Darstellung aktiviert wird, stellen einige Kontrollen eine Verbindung für Meldungen her, die nur im aktiven Zustand gültig sind. Das Deaktivieren der Darstellung unterbricht diese Verbindungen.
Verfahren, welche die Kontrolle verwendet, um Verbindungen zu Meldungsgebern herzustellen und diese abzubrechen, welche einen Einfluß darauf haben, ob die Kontrolle aktiviert ist. ConnectEnabledNotifiers stellt Verbindungen zu Meldungsgebern her, die durch Befehle festgelegt werden, wenn die Kontrolle geöffnet ist. Disconnectenablednotifiers unterbricht diese Verbindungen, wenn die Kontrolle geschlossen wird.
Verfahren, die Meldungen empfangen, welche anzeigen, daß etwas geschehen ist, was die Darstellung eines Datenwertes der Kontrolle beeinflußt. Diese Verfahren führen keine Maßnahmen standardmäßig aus.
Verfahren für Meldungen. CreateInterest erzeugt ein von der Kontrollinstanz spezialisiertes Interesse. Notify (Benachrichtigen) ist überlastet, um eine Meldung zu senden und das Interesse zu schlucken.
Das Kontrollinteresse
Ein einziger Meldungsgeber wird von vielen Kontroll-Unterklassen gemeinsam verwendet. Um Interesse an einer bestimmten Kontrollinstanz anzumelden, muß das Interesse spezialisiert werden. Ein Kontrollinteresse ist ein Interesse, das einen Zeiger zu einer bestimmten Kontrolle enthält. Diese Klasse ist eine interne Klasse, die für gewöhnlich so verwendet wird, wie sie ist, ohne Unterklasseneinteilung.

Die Kontrollmeldung

Ein einziger Meldungsgeber wird von vielen Kontroll- Unterklassen gemeinsam verwendet. Um zu unterscheiden, welche Kontrolle die Meldung gesandt hat, muß die Meldung spezialisiert werden. Eine Kontrollmeldung ist eine Meldung, die einen Zeiger zur Kontrolle enthält, welche die Meldung gesandt hat. Diese Klasse wird für gewöhnlich so verwendet, wie sie ist, ohne Unterklasseneinteilung.

Der Kontrolldarsteller

Ein Kontrolldarsteller umhüllt eine Kontrolle, so daß sie in einem Darstellungsdateneinkapsler enthalten sein kann. Er implementiert bestimmte Standardverhalten, welche alle Darstellerobjekte implementieren. Diese Klasse wird für gewöhnlich so verwendet wird, wie sie ist, ohne Unterklasseneinteilung.
Verfahren, die aufgerufen werden, wenn die Darstellung geöffnet und geschlossen wird. Sie führen keine Maßnahmen standardmäßig durch. Eine Unterklasse muß diese Verfahren für das umhüllte Objekt implementieren. Für Kontrollen werden diese Verfahren direkt zur Kontrolle weitergeleitet. Wenn die Darstellung geöffnet wird, stellt die Kontrolle eine Verbindung für die Meldungen her, die ihren Zustand beeinflussen könnten. Beim Schließen werden die Verbindungen abgebrochen.
Verfahren, die aufgerufen werden, wenn die Darstellung aktiviert und deaktiviert wird. Sie führen keine Maßnahmen standardmäßig durch. Eine Unterklasse muß diese Verfahren für das umhüllte Objekt implementieren. Für Kontrollen werden diese Verfahren direkt zur Kontrolle weitergeleitet. Wenn die Darstellung aktiviert wird, stellen einige Kontrollen Verbindungen für Meldungen her, die nur im aktiven Zustand gültig sind. Bei Deaktivierung werden die Verbindungen abgebrochen.

TControlSelection (TKontrollAuswahl)

Eine Kontrollauswahl bestimmt eine einzige Kontrolle und gegebenenfalls einen darin enthaltenen Befehl, die in einem Kontrolldarsteller eingehüllt und in einer Darstellung gespeichert ist.
Verfahren für den Zugriff auf einen Befehl innerhalb der Kontrolle. Diese können einen ungültigen Wert zurückgeben, wenn kein Befehl festgelegt wurde.

TUniControl (TUniKontrolle)

Eine Unikontrolle ist die abstrakte Basisklasse für Kontrollen, welche einen einzelnen Befehl darstellen, und die den Befehl nach geeigneter Anwenderinteraktion ausführen läßt. Beispiele für diese Art von Kontrollen sind Knöpfe und Auswahlfelder.
Verfahren zum Festlegen des Befehls, der vorhanden ist und von der Kontrolle ausgeführt wird. Eine Meldung wird zu angemeldeten Verbindungen gesandt, wenn der Befehl geändert wird.
Verfahren, welche die Kontrolle verwendet, um Verbindungen mit Meldungsgebern herzustellen und abzubrechen, welche einen Einfluß darauf haben, ob die Kontrolle aktiviert ist.
ConnectEnabledNotifiers stellt Verbindungen zu Meldungsgebern her, die durch Befehle festgelegt werden, wenn die Kontrolle geöffnet ist. DisconnectEnabledNotifiers unterbricht diese Verbindungen, wenn die Kontrolle geschlossen wird.
Verfahren, das Meldungen empfängt, die anzeigen, daß etwas geschehen ist, was einen Einfluß darauf hat, ob die Kontrolle aktiviert werden soll. UpdateEnabled prüft, ob der Befehl aktiv ist, und ruft je nach Bedarf entweder Enable (Aktivieren) oder Disable (Deaktivieren) auf.
Verfahren, das eine Kontrolle verwendet, um eine Verbindung mit Meldungsgebern herzustellen oder abzubrechen, welche einen Einfluß auf die Darstellung eines Datenwertes einer Kontrolle haben. ConnectDataNotifiers stellt eine Verbindung mit den durch Befehle festgelegten Meldungsgebern her, wenn die Kontrolle geöffnet ist. DisconnectDataNotifiers trennt diese Verbindungen, wenn die Kontrolle geschlossen ist. Kontrollen, die keinen Datenwert darstellen (z.B. Knopf), können ConnectDataNotifiers außer Kraft setzen, um nichts zu tun.

TButton (TKnopf)

Ein Knopf ist eine Unikontrolle, welche ihre Befehle ausführt, wenn der Knopf gedrückt wird. Diese Klasse wird normalerweise ohne Unterklassenbildung verwendet; einfach den Befehl einstellen, und damit hat sich's.
Verfahren, die aufgerufen werden, wenn die Darstellung aktiviert und deaktiviert wird. Wenn die Darstellung aktiviert wird, stellen manche Kontrollen Verbindungen für Meldungsgeber her, die nur im aktiven Zustand gültig sind. Bei Deaktivierung werden diese Verbindungen unterbrochen. Wenn die Darstellung aktiviert wird, werden Knöpfe für schlüsseläquivalente Meldung angemeldet. Diese Verbindung wird unterbrochen, wenn die Darstellung deaktiviert wird.
Verfahren, das die Kontrolle verwendet, um Verbindungen mit Meldungsgebern herzustellen und abzubrechen, welche Auswirkungen auf die Darstellung eines Datenwertes der Kontrolle haben. ConnectDataNotifiers stellt eine Verbindung mit dem Meldungsgeber her, der von Befehlen festgelegt wird, wenn die Kontrolle geöffnet ist. Disconnectdatanotifiers unterbricht diese Verbindungen, wenn die Kontrolle geschlossen wird. Kontrollen, die keinen Datenwert darstellen (z.B. Knopf), können ConnectDataNotifiers außer Kraft setzen, um nichts zu tun.

Das Auswahlfeld

Ein Auswahlfeld ist die Anwenderschnittstelle zu einem Befehl, der einen Boolschen Wert einstellt. Nach geeigneter Anwenderinteraktion ruft das Auswahlfeld ein Befehlsverfahren auf, um den Wert zu ändern und den Befehl auszuführen. Diese Klasse wird normalerweise ohne Unterklassenbildung verwendet; einfach den Befehl, dessen Wertholer und Werteinsteller einstellen, und damit hat sich's.

Der Schieberegler

Ein Schieberegler ist eine Unikontrolle, welche einen einzelnen Fließkommawert darstellt und ermöglicht, daß dieser nach entsprechender Anwenderinteraktion geändert wird. Beispiele für Schieberegler wurden in Figur 9 und 10 dargestellt.

TMultiControl (TMehrfachKontrolle)

Eine Mehrfachkontrolle ist die abstrakte Basisklasse für Kontrollen, welche mehrere Befehle darstellen und sie nach geeigneter Anwenderinteraktion zur Ausführung bringen. Beispiele dieses Kontrolltyps sind Radioknöpfe und Menüs.

TRadioButton (TRadioKnopf)

Ein Radioknopf ist eine Mehrfachkontrolle, welche zwei oder mehrere Boolsche Werte darstellt und diese nach entsprechender Anwenderinteraktion ändern läßt. Der Radioknopf zwingt dazu, exakt einen Knopf auszuwählen, wie dies in Figur 11 dargestellt ist. Bei der Auswahl von Papier wird der Kreis bei 1100 schwarz ausgefüllt. Bei der Auswahl von Plastik wird der Kreis bei 1110 ausgewählt. Beide können nicht gleichzeitig ausgewählt werden.

TCommand (TBefehl)

Ein Befehlt kapselt eine Anforderung in ein Objekt oder eine Reihe von Objekten ein, um eine bestimmte Maßnahme auszuführen. Befehle werden für gewöhnlich als Reaktion auf eine Endanwendermaßnahme wie zum Beispiel das Drücken eines Knopfes, das Auswählen eines Menüpunktes oder durch direkte Manipulation ausgeführt. Befehle sind in der Lage, verschiedene Informationsteile über sie selbst (z.B. Bezeichnung, Grafik, Schlüsseläquivalent, ob aktiv oder nicht) anzubieten, die von einer Kontrolle verwendet werden können, um deren Aussehen zu bestimmen. Unterklassen müssen ein Verfahren zur Überprüfung der momentanen Auswahl, des aktiven Anwenderschnittstellenelementes oder anderer Parameter implementieren, um zu entscheiden, ob der Befehl aktiv ist. Unterklassen müssen die 'Hole aktive Interessen'-Liste außer Kraft setzen, um Meldungsinteressen zurückzugeben, die beeinflussen können, ob dieser Befehl aktiv ist.
Figur 12 ist ein Flußdiagramm, welches die detaillierte Logik gemäß der vorliegenden Erfindung darstellt. Die Flußdiagrammlogik beginnt bei 1200, und die Kontrolle geht direkt zu Funktionsblock 1210 weiter, wo Befehlsobjekte einem Menü hinzugefügt werden. Die von diesem Funktionsblock ausgeführten Schritte sind folgende: 1) Menüpunkt von einem Befehl erstellen, wobei ein Menüpunkt eine andere Objektdatenstruktur ist, die einen Befehl enthält; 2) einen Menüpunkt einer Liste von Menüpunkten hinzufügen, und 3) die Menüerscheinung in der Datenstruktur fValid (fGültig) als ungültig markieren. Danach, wenn das Menü heruntergezogen wird, wird die Erscheinung aufgrund des Systemzustandes neu berechnet.
Jedes Menü ist eine Ansicht. Ansichten enthalten Informationen bezüglich Größe und Position. Jedes Menü enthält eine Liste von Menüpunkten. Jeder Menüpunkt enthält einen Befehl und Variablen, welche dessen momentane Erscheinung reflektieren. Dies umfaßt auch, ob der Menüpunkt aktiviert ist (Boolean fEnabled), seine Bezeichnung (TTextLabel fNa- me), seine Grafik (TGraphicLabel fGraphic), und ob seine Erscheinung momentan gültig ist (Boolean fValid). Jede dieser Variablen wird bestimmt, indem der Befehl abgefragt wird, wenn der Menüpunkt erzeugt wird.
Als nächstes wird eine Abfrage an das Kommandoobjekt für Meldungsinteressen gesandt, wie dies im Funktionsblock 1220 dargestellt ist. Jeder Befehl verfügt über vier Verfahren für die Verbindung für unterschiedliche Arten von Meldungen: 1) Meldungen, die seine Bezeichnung beeinflussen; ii) Meldungen, die eine Grafik beeinflussen, iii) Meldungen, die einen Einfluß darauf haben, ob er aktiv ist, und iv) Meldungen, welche Daten beeinflussen. In diesem Fall stellt der gerade für den Befehl erzeugte Menüpunkt eine Verbindung für aktive Meldung dar. Er tut dies, indem er ein Verbindungsobjekt an ConnectActive weitergibt. Der Befehl ist danach verantwortlich für das Verbinden des Verbindungsobjektes mit Meldungsgebern, die einen Einfluß darauf haben, ob der Befehl aktiv ist. Danach wird die Kontrolle weitergegeben zum Funktionsblock 1230, um einen Befehl bezüglich des aktivierten Zustandes abzufragen, wenn es notwendig ist, einen Menüpunkt zu zeichnen. Um einen Menüpunkt zu zeichnen, ruft der Menüpunkt das Verfahren "IsActive" für seinen Befehl auf. Der Befehl prüft jeden beliebigen Systemzustand und gibt zurück, ob er aktiv ist, wie dies im Entscheidungsblock 1240 im momentanen Kontext dargestellt ist (z.B. sind einige Befehle nur aktiv, wenn ein bestimmter Objekttyp ausgewählt ist). Danach aktualisiert ein Menüpunkt seinen internen Zustand (ein Boolscher Wert in jedem Menüpunkt) und sein Aussehen, wie dies im Funktionsblock 1250 und 1260 dargestellt ist, um dem Wert zu entsprechen, der vom Befehl zurückgegeben wird.
Wenn eine Anwendermaßnahme einen Befehl aufruft, wie dies im Eingabeblock 1270 dargestellt ist, wird vom Anwender die Ausführung eines Befehls aufgerufen. Dies kann aus einem Menüpunkt, einer Kontrolle oder durch direkte Manipulation eines Objektes geschehen. Diese Maßnahme verursacht einen zu ändernden Dokumentenzustand, wie dies im Funktionsblock 1280 dargestellt ist, und ein Dokument sendet eine Meldung, wie sie im Funktionsblock 1290 dargestellt ist. Wenn ein Dokument eine Meldung sendet, werden die folgenden Schritte ausgeführt: 1) jeder beliebige Menüpunkt (oder eine andere Kontrolle), der für die vom Dokument gesendete Meldung verbunden ist, empfängt eine Meldungsnachricht. Diese Nachricht umfaßt die Bezeichnung der Veränderung sowie einen Zeiger zum Objekt, das die Meldung gesendet hat; 2) ein Menüpunkt aktualisiert daraufhin seinen Zustand, und die Kontrolle wird zurück zum Funktionsblock 1230 für die weitere Verarbeitung gegeben.
Figur 13 ist eine Darstellung einer Anzeige gemäß der vorliegenden Erfindung. Der Menüpunkt ist Edit (Bearbeiten) 1300 und verfügt über eine Anzahl an damit zusammenhängenden Untermenüpunkten. Undo (Rückgängigmachen) 1310 ist ein aktiver Menüpunkt und kann daher ausgewählt werden, um die damit im Zusammenhang stehenden Funktionen auszuführen. Redo (Wiederholen) 1320 ist inaktiv und wird daher hellgrau dargestellt und kann zu diesem Zeitpunkt nicht ausgewählt werden. Ein Auswahlfeld ist ebenfalls bei 1360 als Teil des Fehlerbeseitungskontrollfeldes 1350 dargestellt.

Darstellungsvorlagen und Dauerhaftigkeit

Die Datendarstellungen werden aus Vorlagen erzeugt und über Sitzungen hinweg in einem Anwenderschnittstellenobjekt gespeichert. Der Behälter für alle Daten in einem System ist ein Modell. Ein Modell enthält Daten und ermöglicht die Manipulation derselben. Der Datenaustausch wird ermöglicht durch Ausschneiden, Kopieren und Einfügen. Der Datenbezug erfolgt durch Auswahlen, Anker und Verknüpfungen. Datenmodelle können ineinander eingebettet werden. Anwender interagieren mit Modellen durch Darstellungen (z.B. Bildsymbol, Daumennagel, Rahmen, Fenster, Dialog, Kontrollfeld), welche von einer damit zusammenhängenden Anwenderschnittstelle zur Verfügung gestellt werden. Datenmodelle geben die Aufgabe der Darstellungserzeugung und der Zugriffsverfahren an ein anderes Objekt weiter, welches als Anwenderschnittstelle bezeichnet wird.
Eine Anwenderschnittstelle ist ein Modell, das eine Reihe von Darstellungen (z.B. Bildsymbol, Daumennagel, Rahmen, Fenster) für ein bestimmtes Modell enthält. Bei Bedarf werden Darstellungen aus jenen ausgewählt, die bereits auf der Grundlage des gewünschten Datentyps, des Anwendernamens, der Position und anderer Kriterien erstellt wurden. Wenn die gewünschte Darstellung nicht gefunden wird, wird eine neue Darstellung erzeugt und der Anwenderschnittstelle durch Kopieren einer solchen aus einem damit im Zusammenhang stehenden Archiv hinzugefügt. Darstellungen können gelöscht werden, wenn dauerhafte Darstellungsinformationen (z.B. Fenstergröße und Position, Bildlaufpositionen) nicht mehr benötigt werden.
Eine Darstellung enthält eine Reihe von darstellbaren Objekten, welche Anwenderschnittstellenelemente (z.B. Menüs, Fenster, Werkzeuge) einhüllen, die zum Betrachten und Manipulieren der Daten verwendet werden. Darstellungen stellen einen Bezug zu den Daten her, welche diese Objekte repräsentieren. Darstellungen installieren oder aktivieren darstellbare Objekte, wenn die Darstellung aktiviert wird. Auf ähnliche Weise werden diese Objekte entfernt oder deaktiviert, wenn die Darstellung deaktivert wird. Darstellungen werden gemäß ihrem Zweck (z.B. Bildsymbol, Daumennagel, Rahmen, Fenster) identifiziert und behalten noch zu bestimmende Kriterien (z.B. Anwenderidentität) für die spätere Auswahl bei.
Eine Darstellung setzt sich aus einer Sammlung darstellbarer Objekte (z.B. Anwenderschnittstellenelemente) zusammen, die am Bildschirm oder auf andere verfügbare Weise dargestellt werden, wenn die Darstellung offen oder aktiv ist.
Darstellungen werden von Vorlagendarstellungen erzeugt, die in einem Archiv enthalten sind. Diese setzen sich aus Objekten wie zum Beispiel Anwenderschnittstellenelementen zusammen, die wiederum aus kleineren Objekten wie zum Beispiel Grafiken und Textketten zusammengesetzt sind.
Ein Archiv ist ein Modell, das eine Reihe von Vorlagenobjekten einschließlich Anwenderschnittstellenelemente (z.B. Fenster, Menüs, Kontrollen, Werkzeuge) und Darstellungen (z.B. Bildsymbol, Daumennagel, Rahmen, Fenster) enthält.

Dialogboxen & Kontrollfelder

Durch Verwendung von Befehlsobjekten auf unterschiedliche Weisen können wir zwei unabhängige Verhalten einer Gruppe von Kontrollen steuern. Das erste ist, ob sie die Daten sofort beeinflussen, oder ob der Anwender zuerst auf OK klikken muß, bevor die Einstellungen wirksam werden. Das zweite ist, ob sie unabhängig voneinander sind, oder ob die Einstellungen einen atomischen Vorgang darstellen.
Kontrollen enthalten Befehle. Wenn der Anwender die Kontrolle manipuliert, stellt die Kontrolle Parameter in den Befehlen ein und bringt diese zur Ausführung. Befehle wirken auf Modelldaten, die von einer Auswahl festgelegt werden.

Sofort

Kontrollen, welche sofortige Auswirkungen auf die Daten haben, enthalten einen Befehl, der eine Auswahl enthält, welche Echtzeit-Modelldaten festlegt. Wenn der Anwender die Kontrolle manipuliert, werden diese Daten durch den Befehl geändert. Wenn sich die Daten ändern, senden sie eine Änderungsmeldung, so daß vom Zustand der Daten abhängige Ansichten und Kontrollen präzise den momentanen Zustand der Daten reflektieren können.

Verzögert

Kontrollen, die entsprechend konstruiert sind, um die Echtzeitdaten nicht zu ändern, müssen stattdessen auf einer Protokollbasis arbeiten. Die Echtzeitmodelldaten werden erst geändert, wenn der Anwender eine weitere Maßnahme durchführt, wie zum Beispiel das Drücken der OK-Taste. Dies geschieht auf zwei Arten:
Die Kontrolle enthält einen Befehl, der eine Auswahl enthält, welche die Kontrolle selbst bestimmt. Wenn der Anwender die Kontrolle manipuliert, ändert der Befehl den Wert der Kontrolle, aber keine anderen Modelldaten. Wenn der Anwender auf OK drückt, ändert ein Befehl im OK-Knopf die Echtzeitmodelldaten, um die Werte in jeder Kontrolle anzupassen, die der Anwender manipuliert haben könnte.
Die Kontrolle enthält einen Befehl, der eine Auswahl enthält, welche einen Parameter des im OK-Knopf enthaltenen Befehls festlegt. Wenn der Anwender die Kontrolle manipuliert, ändert der Befehl den Befehl des OK-Knopfes. Wenn der Anwender den OK-Knopf drückt, ändert der Befehl des OK- Knopfes die Echtzeitmodelldaten, um die darin enthaltenen Werte anzupassen.

Unabhängig

Kontrollen, die unabhängig voneinander agieren, erfordern Darstellungsmaßnahmen, die einzeln rückgängig gemacht werden können, nachdem die Kontrollfeld- oder Dialogsitzung abgeschlossen ist. Dies ist das normale Verhalten von Befehlen, nachdem sie von Kontrollen ausgeführt wurden.

Atomisch

Andere Reihen von Kontrollen sind so konstruiert, daß sie zusammenarbeiten, und diese sollten als atomischer Vorgang rückgängig gemacht und wiederholt werden. Dies geschieht dadurch, indem eine Markierung auf den Rückgängigmachen- Stapel gegeben wird, wenn die Dialogbox oder die Kontrolle gestartet werden. Nach Beendigung werden alle Befehle, die seit der Anbringung der Markierung auf dem Rückgängigmachen-Stapel entweder durch Entlassen des Kontrollfeldes oder durch Drücken des OK-Knopfes durch den Anwender (wie in II B oben) ausgeführt wurden, in eine einzige Befehlsgruppe zusammengefaßt. Diese Gruppe kann danach als einzelne Gruppe rückgängig gemacht oder wiederholt werden.

ABBRUCH

Kontrollfelder, die eine ABBRUCH-Taste enthalten (normalerweise gemeinsam mit einem OK-Knopf, wie in II B oben), verwenden eine Technik, die jener ähnlich ist, wie sie in III B oben beschrieben wurde. Eine Markierung wird auf den Rückgängigmachen-Stapel gegeben, wenn die Dialogbox oder das Kontrollfeld gestartet werden. Wenn der Anwender die ABBRUCH-Taste drückt, werden alle seit der Markierung auf den Rückgängigmachen-Stapel gegebenen Befehle rückgängig gemacht. Diese Technik arbeitet unabhängig davon, ob die Kontrollen die Daten sofort beeinflussen oder nicht.

Atomische Befehlsausführung in Dialogboxen

Das Objekt, mit denen Anwender interagieren, um andere Objekte oder Daten zu manipulieren, wird als eine Kontrolle bezeichnet. Beispiele für Kontrollen sind Menüs, Knöpfe, Auswahlfelder und Radioknöpfe. Jede Kontrolle enthält einen Befehl, der eine Endanwendermaßnahme implementiert. Befehle wirken auf Daten, die von einem Auswahlobjekt festgelegt werden. Wenn der Anwender die Kontrolle manipuliert, stellt diese Parameter im Befehl ein und bringt diesen zur Ausführung, wodurch der Datenwert geändert wird.
Kontrollen, die unabhängig voneinander arbeiten, erfordern Darstellungsmaßnahmen, die einzeln rückgängig gemacht werden können, nachdem das Kontrollfeld oder die Dialogsitzung abgeschlossen wurden. Dies ist das normale Verhalten von Befehlen, nachdem sie von Kontrollen ausgeführt wurden. Andere Reihen von Kontrollen sind so ausgelegt, daß sie zusammenarbeiten und als atomischer Vorgang rückgängig gemacht und wiederholt werden sollten. Dies ist der Gegenstand dieser Erfindung.
Die detaillierte Logik der atomischen Ausführung wird im Flußdiagramm in Figur 14 dargestellt. Die Verarbeitung beginnt am Punkt 1400, wo die Kontrolle sofort zum Funktionsblock 1410 weitergegeben wird, wo eine Dialogbox aktiviert wird. Wenn die Dialogbox aktiviert ist, wird eine Markierung auf den Rückgängigmachen-Stapel gesetzt. Der Rückgängigmachen-Stapel ist eine Liste aller Befehle, die der Anwender ausgeführt hat. Wenn Rückgängigmachen gedrückt wird, wird der oberste Befehl am Stapel rückgängig gemacht. Wenn er nicht sofort wiederholt wird, wird er weggeworfen. Dann, am Funktionsblock 1410, wird eine Anwendermanipulation einer Kontrolle erkannt. Die Manipulation einer Kontrolle ändert den Datenwert des Befehls auf geeignete Weise, wie dies im Funktionsblock 1430 dargelegt ist, und führt die Kontrolle aus. Zum Beispiel schaltet ein Auswahlfeld das fChecked-Feld des Befehls zwischen 0 und 1 hin und her. Schließlich wird der Befehl am Rückgängigmachen-Stapel aufgezeichnet, so daß er in der Folge rückgängig gemacht werden kann, wie dies im Funktionsblock 1440 dargestellt ist.
Wenn ein Anwender in der Folge die einzelnen Kontrollen in der Dialogbox manipuliert, wie dies im Entscheidungsblock 1450 erkannt wird, so wird die Kontrolle zum Funktionsblock 1430 weitergegeben. Wenn jedoch ein Anwender OK drückt, wie dies im Entscheidungsblock 1460 erkannt wird, dann wird die Kontrolle zum Funktionsblock 1420 weitergegeben. Wenn schließlich die einzelnen Kontrollen in der Dialogbox zur Zufriedenheit des Anwenders eingestellt sind, drückt der Anwender den OK-Knopf. Es werden alle Befehle ausgeführt, die seit der Plazierung der Markierung am Rückgängigmachen- Stapel im Funktionsblock 1440 in eine einzige Befehlsgruppe zusammengesammelt wurden, und zurück auf den Rückgängigmachen-Stapel gegeben, wie dies im Funktionsblock 1470 dargestellt ist. Eine Befehlsgruppe ist ein Befehl, der viele Befehle zusammensammelt. Beim Ausführen, Rückgängigmachen oder Wiederholen wird von der Befehlsgruppe jeder einzelne Befehl der Reihe nach ausgeführt, rückgängiggemacht oder wiederholt. Die Befehlsgruppe wird dann zurück auf den Rückgängigmachen-Stapel gesetzt, wo sie als einzelner atomischer Vorgang rückgängig gemacht oder wiederholt werden kann.

Verzögerte Befehlsausführung in Dialogboxen

Das Objekt, mit dem Anwender interagieren, um andere Objekte oder Daten zu manipulieren, wird als eine Kontrolle bezeichnet. Beispielkontrollen sind Menüs, Knöpfe, Auswahlfelder und Radioknöpfe. Jede Kontrolle enthält einen Befehl, der eine Endanwendermaßnahme implementiert. Befehle wirken auf Daten, die von einem Auswahlobjekt festgelegt werden. Wenn der Anwender die Kontrolle manipuliert, stellt diese Parameter im Befehl ein und bringt diesen zur Ausführung, wodurch der Datenwert geändert wird. Ein Aspekt der vorliegenden Erfindung ist das Verzögern der Änderung von Daten, bis der Anwender eine weitere Maßnahme ausführt. So kann es zum Beispiel möglich sein, daß Kontrollen in einer Dialogbox keine Datenwerte ändern, bis der Anwender den OK- Knopf drückt.
Wenn eine Kontrolle erzeugt wird, muß ein Befehl festgelegt werden. Die Kontrolle erzeugt eine Kopie dieses Befehls und speichert ihn im Feld fCommand. Wenn der Befehl Datenwerte liefert, muß auch ein Zeiger zu den geeigneten Get- (Holen) und Set- (Einstellen) Verfahren des Befehls festgelegt werden. Die Kontrolle speichert diese Verfahrenszeiger in den Feldern fGetmethod bzw. fSetmethod. Die vom Befehl veränderten Daten werden von einem Auswahlobjekt festgelegt. Normalerweise legt dieses Auswahlobjekt echte Modeildaten fest. xx Stattdessen legt ein Auswahlobjekt den Datenwert innerhalb des Befehles des OK-Knopfes fest.
Wenn ein Anwender die Kontrolle manipuliert, wird der Befehl der Kontrolle ausgeführt, und ein Datenwert innerhalb des Befehls des OK-Knopfes wird geändert. Wenn ein Anwender die einzelnen Kontrollen in der Dialogbox manipuliert, wird der Befehl der Kontrolle ausgeführt, und ein Datenwert innerhalb des Befehles des OK-Knopfes wird geändert. Wenn daher ein Anwender den OK-Knopf drückt, aktualisiert der Befehl im OK-Knopf die echten Modelldaten, damit sie den Datenwerten entsprechen, die in ihm selbst enthalten sind, so wie sie von den Befehlen der Kontrolle manipuliert wurden. Dieser Verarbeitungsvorgang wird wiederholt, bis die Kontrollverarbeitung abgeschlossen ist.

Beschriftungen

Beschriftungen sind grafische Objekte, die eine Grafik oder eine Textkette enthalten. Sie werden verwendet, um Fenster, Menüs, Knöpfe und andere Kontrollen zu kennzeichnen. Beschriftungen sind in der Lage, ihr Aussehen je nach dem Zustand ihres Behälters zu verändern. Sie werden auf einem mittelgrauen Hintergrund gezeichnet und erscheinen nur dann in ihrer natürlichen Form, wenn kein spezieller Zustand angezeigt werden muß. Beschriftungen ändern ihr Aussehen, wenn sie inaktiv, deaktiviert oder ausgewählt sind.

Inaktiv

Fenstertitel werden auf inaktiv gesetzt, wenn das Fenster nicht ganz vorne steht. Auf ähnliche Weise werden Kontrollbeschriftungen auf inaktiv gesetzt, wenn die Kontrolle sich nicht im vordersten Fenster oder einem anderen Behälter befindet. Grafische Beschriftungen werden mit 55% Weiß gemischt, wenn sie inaktiv sind, damit sie halbhell erscheinen. Bei Textbeschriftungen wird die inaktive Farbe von der natürlichen Farbe abgeleitet, indem die Sättigungskomponente des HSV-Farbmodells manipuliert wird. Im inaktiven Zustand wird die Sättigung mit 0,45 multipliziert.

Deaktiviert

Kontrollbeschriftungen werden auf halbhell gestellt, wenn die Kontrolle in einem bestimmten Zusammenhang nicht zutreffend ist. Grafikbeschriftungen werden im inaktiven Zustand mit 46% Weiß gemischt, damit sie halbhell erscheinen. Für Textbeschriftungen wird die deaktivierte Farbe von der natürlichen Farbe abgeleitet, indem die Sättigungskomponente des HSV-Farbmodells manipuliert wird. Die Sättigung wird für den deaktivierten Zustand mit 0,54 multipliziert.

Ausgewählt

Kontrollbeschriftungen werden hervorgehoben, wenn die Kontrollen manipuliert werden. Grafiken und Text werden für die Hervorhebung in ihrem natürlichen Zustand gezeichnet, jedoch auf einem weißen Hintergrund.

Intelligente Kontrollbeschriftungen

Kontrollen verwenden einen Befehl, um den momentanen Zustand des Objektes oder der Daten zu bestimmen. Nach geeigneten Interaktionen mit dem Anwender aktualisiert die Kontrolle die Parameter des Befehls und bringt ihn zur Ausführung. Zum Beispiel stellt ein Auswahlfeld einen Befehlsparameter auf Ein oder Aus und führt dann den Befehl aus, um einen Datenwert zu ändern. Kontrollen zeigen eine Beschriftung an, um deren Funktion darzustellen. Bei dieser Beschriftung handelt es sich um ein grafisches Objekt, welches eine Grafik oder eine Textkette enthält. Wenn die Kontrolle ihren Zustand ändert, paßt die Beschriftung automatisch ihr Aussehen an, ohne daß der Entwickler einen zusätzlichen Code schreiben muß. Diese Zustände umfassen aktiv/inaktiv, aktiviert/deaktiviert, und ausgewählt/nicht ausgewählt.
Figur 15 zeigt die detaillierte Logik im Zusammenhang mit der intelligenten Beschriftungsverarbeitung, welche am Punkt 1500 beginnt, wo die Kontrolle sofort zu 1510 für die Initialisierung der intelligenten Beschriftung weitergegeben wird. Bei Erzeugung der Kontrolle wird die Beschriftung mit einer Textkette oder Grafik initialisiert, die von ihrem entsprechenden Befehl zur Verfügung gestellt wird. Jeder Befehl bietet zu diesem Zweck Verfahren, die als Get- Graphic und Getname bezeichnet werden. Die Kontrolle teilt der Beschriftung mit, ob sie im Moment aktiv oder inaktiv ist, indem das Verfahren Setactive aufgerufen wird. Auf ähnliche Weise ruft die Kontrolle das Verfahren SetEnabled auf, um der Beschriftung mitzuteilen, ob sie aktiviert ist, und SetSelected, um der Beschriftung mitzuteilen, ob sie momentan von einem Anwender ausgewählt ist.
Der nächste Schritt bei der Verarbeitung der intelligenten Beschriftung erfolgt beim Funktionsblock 1520, wenn die Beschriftung gezeichnet wird. Wenn die Kontrolle aktiviert ist, ruft sie das Draw-Verfahren (Zeichenverfahren) ihrer Beschriftung auf, wodurch die Beschriftung am Bildschirm erscheint. Im inaktiven Fall wird die Beschriftung weniger intensiv gezeichnet als normal. Dies erfolgt durch Manipulation der Sättigungskomponenten des HSV-Farbmodells. Die Sättigung wird im inaktiven Fall mit 0,45 multipliziert. Im deaktivierten Zustand wird die Beschriftung weniger intensiv gezeichnet als normal. Dies erfolgt durch Manipulation der Sättigungskomponenten des HSV-Farbmodells. Die Sättigung wird mit 0,54 multipliziert, wenn die Beschriftung deaktiviert ist. Im Falle einer Auswahl erscheint die Beschriftung auf einem erhellten Hintergrund. Beschriftungen werden normalerweise auf einem mittelgrauen Hintergrund gezeichnet. Bei Hervorhebung werden die Beschriftungen auf einem weißen Hintergrund gezeichnet. Andernfalls wird die Beschriftung normal gezeichnet.
Die nächste Verarbeitung erfolgt, wenn eine Beschriftung aktiviert/deaktiviert wird, wie dies im Funktionsblock 1530 dargestellt wird. Wenn die Kontrolle aktiviert oder deaktiviert wird, teilt sie dies der Beschriftung durch Aufruf des SetActive-Verfahrens mit. Die Kontrolle zeigt dann an, daß ihr Aussehen aktualisiert werden muß, indem sie Invalidate mit einem Argument aufruft, das auf den Abschnitt am Bildschirm hinweist, der neu gezeichnet werden muß. Danach erfolgt beim Funktionsblock 1540 die Verarbeitung, wenn eine Kontrolle aktiviert/deaktiviert wird. Wenn die Kontrolle aktiviert oder deaktiviert ist, teilt sie dies der Beschriftung durch Aufrufen des SetEnabled-Verfahrens mit. Die Kontrolle weist dann darauf hin, daß ihr Aussehen aktualisiert werden muß, indem sie Invalidate mit einem Argument aufruft, das auf den Abschnitt am Bildschirm hinweist, der neu gezeichnet werden muß.
Danach wird am Entscheidungsblock 1550 eine Überprüfung durchgeführt, um zu bestimmen, ob eine Kontrolle ausgewählt oder nicht ausgewählt ist. Wenn die Kontrolle ausgewählt oder nicht ausgewählt ist, teilt sie dies der Beschriftung durch Aufruf des SetSelected-Verfahrens mit. Die Kontrolle weist dann darauf hin, daß ihr Aussehen aktualisiert werden muß, indem sie Invalidate mit einem Argument aufruft, das auf den Abschnitt am Bildschirm hinweist, der neu gezeichnet werden muß, und die Kontrolle wird zum Funktionsblock 1520 für die weitere Verarbeitung weitergegeben.

Intelligente Fensterbeschriftungen

In einem Fenster wird ein Titel dargestellt, um dessen Zweck zu kennzeichnen. Der Titel für ein Fenster zum Bearbeiten eines Dokumentes ist zum Beispiel für gewöhnlich die Bezeichnung des Dokumentes. Es wird ein Beschriftungsobjekt verwendet, um den Titel zu verfolgen. Bei dieser Beschriftung handelt es sich um ein graphisches Objekt, welches eine Grafik oder eine Textkette enthält. Wenn das Fenster seinen Zustand ändert, paßt die Beschriftung automatisch ihr Aussehen entsprechend an, ohne daß der Entwickler dazu einen zusätzlichen Code schreiben müßte. Fenster können entweder aktiv oder inaktiv sein. Die Verarbeitung von intelligenten Fensterbeschriftungen wird in einem Flußdiagramm in Figur 16 dargestellt, und die detaillierte Logik wird in einer Referenz dazu erklärt.
Die Verarbeitung beginnt in Figur 16 am Punkt 1600, wo die Kontrolle sofort zum Funktionsblock 1610 weitergegeben wird, um den Titel zu initialisieren. Ein Fenstertitel wird von einem Entwickler festgelegt, wenn ein Fenster erzeugt wird. Dieser Titel wird in einem TLabel-Objekt gespeichert, das die Bezeichnung fTitle trägt. Die Kontrolle teilt dem Titel mit, ob sie momentan aktiv oder inaktiv ist, indem sie das Verfahren SetActive aufruft. Dann, der xx am Funktionsblock 1620. Wenn ein Fenster gezeichnet wird, ruft es das Draw-Verfahren (Zeichnungsverfahren) seines fTitle- Objektes auf, wodurch der Titel am Bildschirm erscheint. Im inaktiven Zustand wird der Titel weniger intensiv gezeichnet als normal. Dies geschieht durch Manipulation der Sättigungskomponente des HSV-Farbmodells. Die Sättigung wird im inaktiven Zustand mit 0,45 multipliziert. Andernfalls wird der Titel normal gezeichnet.
Der nächste Schritt wird am Funktionsblock 1630 verarbeitet, wenn der Titel aktiviert/deaktiviert ist. Wenn ein Fenster aktiviert oder deaktiviert wird, teilt es dies seinem fTitle-Objekt durch Aufruf des Setactive-Verfahrens mit. Das Fenster weist dann darauf hin, daß sein Aussehen aktualisiert werden muß, indem es Invalidate mit einem Argument aufruft, das auf den Abschnitt am Bildschirm hinweist, der neu gezeichnet werden muß. Danach geht die Kontrolle zum Funktionsblock 1620 weiter, um den Titel neu zu zeichnen, damit sein neuer Zustand entsprechend reflektiert wird.

Verzierungen

Zahlreiche visuelle Aspekte der Anwenderschnittstellenelemente sind vielen Elementen gemein. Beispiele dafür sind Schatten, Umrandungen und Beschriftungen. Die einzelnen visuellen Merkmale werden als Verzierungen bezeichnet. Verzierungen können mit anderen Grafiken kombiniert werden, um das visuelle Aussehen bestimmter Anwenderschnittstellenelemente, wie zum Beispiel Fenstern und Kontrollen, zu formen. Die gegenständliche Erfindung unterstützt viele unterschiedliche Arten von Verzierungen.

Hintergründe

Eine Verzierung, die hinter einem anderen Objekt gezeichnet wird, wird Hintergrund genannt. Eine Art von Hintergrund wird so gezeichnet, daß er bündig mit der umgebenden Zeichnungsoberfläche erscheint. Er kann mit oder ohne Rahmen gezeichnet werden. Eine andere Art von Hintergrund wird mit Hervorhebung und Schatten gezeichnet, so daß er oberhalb der umgebenden Zeichnungsoberfläche zu liegen scheint. Die letzte Art von Hintergrund wird mit Hervorhebung und Schatten gezeichnet, so daß er unterhalb der umgebenden Zeichnungsoberfläche zu liegen scheint.
Eine beispielhafte Verwendung für diese Hintergründe ist ein Knopf. Normalerweise ist der Text oder die Grafik, mit welcher der Knopf beschrieben wird, auf einem erhöhten Hintergrund gezeichnet. Beim Drücken durch den Anwender werden der Text oder die Grafik auf einem eingedrückten Hintergrund neu gezeichnet. Wenn der Knopf inaktiv ist, also wenn zum Beispiel ein anderes Fenster aktiv ist, könnten der Text oder die Grafik halbhell auf einem ebenen Hintergrund gezeichnet werden.

Umrandungen

Eine Verzierung, welche ein anderes Objekt oder einen Bereich umgibt, wird als Umrandung bezeichnet. Beispiele für Umrandungen sind Rahmen und Schatten. Ein Rahmen ist eine Umrandung, welche eine andere Grafik umgibt, ähnlich wie ein Rahmen, das ein Bild in der wirklichen Welt umgibt. Ebenso wie Hintergründe können auch Rahmen so gezeichnet werden, daß sie unterhalb oder oberhalb einer umgebenden Zeichnungsoberfläche oder bündig mit dieser erscheinen. Ein Schatten ist ein spezieller Typ von Umrandung, der einen Schatten rund um ein Objekt hinzufügt, wodurch das Objekt dann so aussieht, als würde es über der Umgebungsoberfläche schweben.

Verzierungsfarben

Zahlreiche visuelle Aspekte von Anwenderschnittstellenelementen sind vielen Elementen gemein. Beispiele sind Schatten, Umrandungen und Beschriftungen. Jedes dieser einzelnen visuellen Merkmale wird als Verzierung bezeichnet. Verzierungen können mit anderen Grafiken kombiniert werden, um das visuelle Aussehen bestimmter Anwenderschnittstellenelemente, wie zum Beispiel von Fenstern und Kontrollen, zu bilden. Einige Verzierungen verwenden Hervorhebung und Schatten, um so zu erscheinen, als ob sie sich unterhalb oder oberhalb der umgebenden Zeichnungsoberfläche befinden würden. Verzierungen sind in der Lage, diese Hervorhebungs- und Schattenfarben automatisch abzuleiten.

Füllfarbe

Die Füllfarbe stellt die primäre Farbe der Verzierungen dar. Alle anderen Farben werden von der Füllfarbe abgeleitet. Die Füllfarbe wird von der Verzierung in einem TColor- Feld mit der Bezeichnung fFillPaint gespeichert. Die Füllfarbe wird normalerweise vom Entwickler festgelegt, wenn die Verzierung erzeugt wird. Wenn jedoch keine Farbe festgelegt wird, wird ein Mittelgrau ausgewählt.

Rahmenfarbe

Die Rahmenfarbe wird verwendet, um eine Linie rund um die Verzierung zu zeichnen, um einen visuellen Kontrast zu schaffen. Die Rahmenfarbe wird von der Verzierung in einem TColor-Feld mit der Bezeichnung fFramePaint gespeichert. Die Rahmenfarbe kann vom Entwickler festgelegt werden, wenn die Verzierung erzeugt wird. Wenn jedoch keine Rahmenfarbe festgelegt wird, wird sie automatisch von der Füllfarbe berechnet. Dies wird durch Manipulation der Sättigungs- und Wertekomponenten des HSV-Farbmodells erreicht. Die Sättigung wird mit vier multipliziert, bei einem Maximalwert von 1. Der Wert wird durch vier dividiert.

Hervorhebungsfarbe

Die Hervorhebungsfarbe wird verwendet, um Linien zu ziehen, wo Licht auf das Objekt auftreffen würde, wenn es ein wirkliches dreidimensionales Objekt wäre. Die Hervorhebungsfarbe wird von der Verzierung in einem TColor-Feld mit der Bezeichnung fHighlightPaint gespeichert. Die Hervorhebungsfarbe kann vom Entwickler festgelegt werden, wenn die Verzierung erzeugt wird. Wenn jedoch keine Hervorhebungsfarbe festgelegt wird, wird sie automatisch von der Füllfarbe berechnet. Dies erfolgt durch Manipulation der Sättigungs- und Wertekomponenten des HSV-Farbmodells. Die Sättigung wird mit 0,8 multipliziert. Der Wert wird mit 1,25 multipliziert, bei einem Maximalwert von 1.

Schattenfarbe

Die Schattenfarbe kann verwendet werden, um Linien zu zeichnen, wo das Objekt schattiert wäre, wenn es ein wirkliches dreidimensionales Objekt wäre. Die Schattenfarbe wird von der Verzierung in einem TColor-Feld mit der Bezeichnung fShadowPaint gespeichert. Die Schattenfarbe kann vom Entwickler festgelegt werden, wenn die Verzierung erzeugt wird. Wenn jedoch keine Schattenfarbe festgelegt wird, wird sie automatisch von der Füllfarbe berechnet. Dies geschieht durch Manipulation der Sättigungs- und Wertekomponenten des HSV-Farbmodells. Die Sättigung wird, bei einem Maximalwert von 1, mit 2 multipliziert. Der Wert wird durch 2 dividiert.

Trennen der Eingabesyntax von der Semantik

Das Manipulieren einer grafischen Anwenderschnittstelle erfolgt durch Bewegen einer Maus, durch das Anklicken von Objekten zur Auswahl derselben, durch Ziehen von Objekten zum Bewegen oder Kopieren derselben und durch Doppelklicken zum Öffnen derselben. Diese Vorgänge werden als direkte Manipulationen oder Interaktionen bezeichnet. Die Reihenfolge von Ereignissen, die dem Drücken, Bewegen und Loslassen einer Maus durch den Anwender entsprechen, werden als Eingabesyntax bezeichnet. Bestimmte Reihenfolgen von Ereignissen werden verwendet, um bestimmte Maßnahmen anzuzeigen, die als semantische Operationen bezeichnet werden.
Die Trennung des Codes, der die Eingabesyntax versteht, vom Code, der semantische Operationen implementiert, ist der Gegenstand dieser Erfindung. Diese Verarbeitung ist in Objekten enthalten, die als Interacts bzw. Interactable bezeichnet werden. Figur 17 zeigt, wie diese Objekte erzeugt werden und wie die Objekte miteinander während einer typischen Interaktion mit einem Objekt kommunizieren, das bewegt und ausgewählt werden kann.
Die Verarbeitung beginnt beim Punkt 1700, wo die Kontrolle sofort zum Funktionsblock 1710 weitergegeben wird, um zu bestimmen, ob die Maustaste gedrückt wurde. Ein Ereignis wird zum Objekt gesendet, das für den Abschnitt des Bildschirms verantwortlich ist, in dem die Maustaste gedrückt wurde. Dieses Objekt wird als eine Ansicht (View) bezeichnet. Dann wird am Funktionsblock 1720 der Interaktor erzeugt, um die Eingabesyntax zu analysieren. Dies geschieht, indem das CreateInteractor-Verfahren der Ansicht aufgerufen wird. Wenn der Interaktor erzeugt wird, werden Zeiger als Parameter weitergegeben, die zu Objekten gerichtet sind, welche mögliche Anwendermaßnahmen implementieren.
Zum Zwecke dieser Diskussion wird angenommen, daß der Anwender die Maustaste auf einem Objekt gedrückt hat, das ausgewählt und bewegt werden kann. In diesem Fall werden ein Objekt, das Auswahl implementiert, und ein Objekt, das Bewegung für das Zielobjekt implementiert, als Parameter an den Interaktor weitergegeben. Die anfängliche Ansicht würde beide diese Verhalten implementieren, oder sie könnten von einem oder zwei getrennten Objekten implementiert werden. Das Objekt oder die Objekte werden gemeinsam als Interactable bezeichnet.
Der Interaktor wird am Funktionsblock 1730 gestartet. Diese Verarbeitung gibt den Interaktor zurück zur Ansicht und beginnt die Verarbeitung des Interaktors. Dies erfolgt durch das Aufrufen des Startverfahrens des Interaktors und durch Weitergabe des ursprünglichen Mausereignisses als Parameter. Das Startverfahren sichert das ursprüngliche Mausereignis im Feld fInitialEvent. Da nur ein Mausereignis bisher verarbeitet wurde, ist die einzig mögliche Maßnahme das Auswählen. Der Interaktor geht in die Auswahl- Betriebsart, indem er den veränderlichen fInteraction-Typ konstant auf kSelect setzt. Er fordert den Interactable auf, die Auswahloperation durch Aufruf seines SelectBegin- Verfahrens zu beginnen.
Danach wartet der Interaktor, bis eine kurze Zeitspanne vergangen ist, wie dies im Funktionsblock 1740 dargestellt ist. Es wird ein neues Mausereignis zum Interaktor gesandt, wenn die Zeit vorüber ist, das auf den momentanen Zustand der Maus hinweist. Wenn danach das System erkennt, daß sich die Maus noch immer am Entscheidungsblock 1750 befindet, wird die Kontrolle zum Funktionsblock 1740 weitergegeben. Andernfalls wird die Kontrolle zum Endblock 1760 weitergegeben. Wenn die Maustaste noch immer gedrückt ist, stellt der Interaktor sicher, daß er sich noch immer im korrekten Zustand befindet und fordert den Interactable auf, die richtige Operation zu implementieren. Der Interaktor ist 'Selecting' (Auswählend), wenn der fInteraction-Typ 'kSelecting' (kAuswählend) ist. Er ist 'Moving' (Bewegend), wenn der fInteraction-Typ 'kMoving' (kBewegend) ist.
Wenn er 'Selecting' ist, vergleicht der Interaktor die momentane Mausposition mit der ursprünglichen Mausposition. Die momentane Mausposition wird erhalten, indem das GetCurrentLocation-Verfahren aufgerufen wird. Die ursprüngliche Mausposition wird durch Aufruf des GetInitialLocation- Verfahrens erhalten. Wenn die beiden gleich sind oder sich nur geringfügig voneinander unterscheiden, wählt der Anwender das Objekt noch immer aus. Der Interaktor fordert dann den Interactable auf, die Auswahloperation durch Aufruf des Selectrepeat-Verfahrens fortzusetzen. Wenn sich die zwei Punkte jedoch um mehr als einen vorherbestimmten Grenzwert unterscheiden, hat der Anwender begonnen, das Objekt zu bewegen. In diesem Fall fordert der Interaktor den Interactable auf, den Auswahlvorgang durch Aufruf des SelectEnd- Verfahrens zu beenden. Danach fordert er den Interactable auf, durch Aufruf des MoveBegin-Verfahrens mit dem Bewegungsvorgang zu beginnen. In jedem dieser Fälle wird die momentane Mausposition als Argument weitergegeben. Im 'Moving'-Fall fordert der Interaktor den Interactable auf, den Bewegungsvorgang durch Aufruf seines MoveRepeat- Verfahrens fortzusetzen. Er gibt die momentane Mausposition als Argument weiter.
Wenn der Anwender die Maustaste losläßt, signalisiert dies das Ende des momentanen Vorganges. Im 'Selecting'-Fall fordert der Interaktor den Interactable auf, den Auswahlvorgang durch Aufruf seines SelectEnd-Verfahrens zu beenden. Im 'Moving'-Fall fordert der Interaktor den Interactable auf, durch Aufruf seines MoveEnd-Verfahrens den Bewegungsvorgang zu beenden.

Lokalisierte Darstellungen

Lokalisierung ist der Vorgang des Aktualisierens einer Anwendung, um einzigartigen Anforderungen einer bestimmten Position zu entsprechen. Dies kann eine Sprachenübersetzung, eine Grafikersetzung und eine Neuausrichtung eines Schnittstellenelementes umfassen. So hängt zum Beispiel der in Beschriftungen, Titeln und Meldungen verwendete Text von der ausgewählten Sprache ab. Seine Richtung und Ausrichtung kann die Anordnung und Ausrichtung eines Menüs, einer Menüzeile, eines Titels, einer Bildlaufleiste oder einer Werkzeugleiste beeinflussen. Auf ähnliche Weise kann die Auswahl von Bildsymbolen und anderen grafischen Symbolen kulturell abhängig sein. Unglücklicherweise ist es sehr teuer, viele lokalisierte Versionen von Anwenderschnittstellenelementen im Speicher zu haben. Stattdessen werden lokalisierte Versionen von Anwenderschnittstellenelementen auf Platte gelagert, bis sie im Speicher benötigt werden.
Desweiteren ist es sehr fehlerträchtig und teuer, alle Anwenderschnittstellenelemente zu verfolgen und zu entscheiden, welche Version zu verwenden ist. Stattdessen wird, wenn ein Anwenderschnittstellenelement benötigt wird, das geeignete automatisch vom System entsprechend der aktuellen Sprache und anderen kulturellen Parametern ausgewählt und in den Speicher eingelesen.
Nach der Lokalisierung werden die Anwenderschnittstellenelemente in einem Platten-Wörterbuch gespeichert. Ein Platten-Wörterbuch ist ein Objekt, das mit Hilfe eines Schlüssels einen Wert ausgibt, nachdem es diesen von der Platte eingelesen hat. Dieses Platten-Wörterbuch wird von einem Objekt verwaltet, das als Archiv bezeichnet wird. Ein Archiv ist dafür verantwortlich, die einzelnen Anwenderschnittstellenelemente zusammenzusetzen, aus denen eine bestimmte Darstellung besteht. Der Vorgang der Auswahl des geeigneten Anwenderschnittstellenelementes wird in Figur 19 dargestellt.
Die Verarbeitung beginnt am Endpunkt 1900 und wird sofort zum Funktionsblock 1910 weitergegeben, wenn ein Anwender eine Darstellung anfordert. Ein Topenpresentation-Befehl wird zum Datenmodell geschickt, um anzuzeigen, daß der Anwender diese Daten betrachten oder bearbeiten will. Ein Befehl wird zum Datenmodell geschickt, um anzuzeigen, daß der Anwender die Daten betrachten oder bearbeiten möchte. Dieser Befehl wird als Topenpresentation-Befehl bezeichnet. Eine Darstellung ist eine Reihe von Anwenderschnittstellenelementen, welche es gemeinsam dem Anwender ermöglichen, einige Daten zu betrachten oder zu bearbeiten. Darstellungen werden über Sitzungen hinweg im Anwenderschnittstellenobjekt gespeichert, wodurch die Kontinuität für den Anwender gewahrt bleibt. Anwenderschnittstellenelemente werden auf Platte gespeichert, bis sie im Speicher benötigt werden. Sie können als Teil einer Datendarstellung benötigt werden, die der Anwender angefordert hat, oder sie können für die Übersetzung oder einen anderen Lokalisierungsvorgang benötigt werden. Jedes Anwenderschnittstellenelement enthält eine Kennung, die auf einzigartige Weise auf dieses Element verweist. Alle lokalisierten Versionen desselben Anwenderschnittstellenelementes verwenden jedoch eine gemeinsame Kennung.
Um die lokalisierten Versionen unterscheiden zu können, werden die bestimmte Sprache, die Schreibrichtung und andere kulturelle Parameter mit jedem einzelnen lokalisierten Anwenderschnittstellenelement abgespeichert. Gemeinsam werden diese Parameter als Szene bezeichnet. Alle Anwenderschnittstellenelemente werden in einer Datei gespeichert. Diese Datei ist wie ein Wörterbuch aufgebaut, mit einem oder mehreren Schlüssel-/Wert-Paaren. Der Schlüssel ist ein Objekt, welches die Kennung und die Szene miteinander verbindet. Der Wert ist das Anwenderschnittstellenelement selbst.
Eine neue Darstellung muß neben dem Funktionsblock 1920 geschaffen werden. Wenn eine geeignete Darstellung noch nicht besteht, muß eine neue von einer Vorlage durch das Anwenderschnittstellenarchiv erzeugt werden. Eine neue Darstellung wird von einer Vorlage erzeugt, die in dem Archiv gespeichert ist, indem dessen Createpresentation-Verfahren aufgerufen wird. Eine Darstellungsart wird an dieses Verfahren als Parameter weitergegeben. Dieser Typ umfaßt Informationen wie den Typ der darzustellenden Daten, ob sie in ihrem eigenen Fenster dargestellt werden sollen oder Teil einer anderen Darstellung sein sollen, und so weiter. Schließlich baut ein Archiv bei Funktionsblock 1930 die Darstellung auf, wobei die Anwenderschnittstellenelemente entsprechend der Szene ausgewählt werden. Wenn das Archiv in der Lage ist, eine Darstellung des festgelegten Typs zu bauen, sammelt es die einzelnen Anwenderschnittstellenelemente zusammen, aus denen die Darstellung besteht, und gibt diese zum Anwenderschnittstellenobjekt zurück.
Für jede Darstellung, die das Archiv erzeugen kann, hat es eine Liste von Anwenderschnittstellenelementenkennungen, aus denen die Darstellung besteht. Die Anwenderschnittstellenelemente werden auf Platte gespeichert und von einem Platten-Wörterbuchobjekt mit der Bezeichnung xx verwaltet. Bei Eingabe eines Schlüssels gibt das Platten-Wörterbuch das entsprechende Anwenderschnittstellenelement wieder zurück. Die Anwenderschnittstellenelementkennung stellt die primäre Komponente dieses Schlüssels dar. Eine sekundäre Komponente des Schlüssels ist die gewünschte Szene. Eine Szene ist ein Objekt, welches die natürliche Sprache und andere kulturelle Attribute des Anwenders festlegt. Die Szene wird automatisch vom Archiv von einem Präferenzen- Dienstleister erhalten. Dieser Dienstleister enthält alle individuellen Präferenzen, die mit einem Anwender in Zusammenhang stehen.
Diese vom Präferenzen-Dienstleister erhaltene Szene wird mit der Kennung zu einem einzigen Objekt kombiniert, das als TUserInterfaceElementKey bezeichnet wird. Dieser Schlüssel wird als Parameter zum GetValue-Verfahren des Platten-Wörterbuchs weitergegeben. Wenn ein Anwenderschnittstellenelement mit einer passenden Kennung und Szene gefunden wird, wird es zurückgegeben und als Teil der Darstellung eingebunden. Andernfalls muß der Szenen-Parameter aus dem Schlüssel weggelassen werden, oder eine andere Szene muß festgelegt werden, bis ein geeignetes Anwenderschnittstellenelement gefunden wird.

Interaktionsrahmenwerksystem

Anwender der grafischen Anwenderschnittstelle eines objektorientierten Betriebssystems verwenden oft eine Maus, klicken auf Objekte, um sie auszuwählen, ziehen Objekte, um sie zu bewegen oder zu kopieren, und doppelklicken auf Objekte, um sie zu öffnen. Diese Vorgänge werden als direkte Manipulationen oder Interaktionen bezeichnet. Die Reihenfolge von Ereignissen, die dem Drücken, Bewegen und Loslassen der Maus durch den Anwender entsprechen, werden als Eingabesyntax bezeichnet. Bestimmte Reihenfolgen von Ereignissen werden verwendet, um bestimmte Maßnahmen anzuzeigen, die als semantische Operationen bezeichnet werden. Diese Erfindung offenbart das Verfahren und die Vorrichtung zum Übersetzen der Eingabesyntax in semantische Operationen für ein Objekt, welches Select (Auswählen), Peek (Spähen), Move (Bewegen), AutoScroll (autom. Bildlauf) und Drag/Drop (Copy) (Ziehen/Fallenlassen (Kopieren) ) unterstützt.
Die Erfindung erkennt, wenn eine Maustaste gedrückt wird, und wendet daraufhin die folgende Logik an:
(a) Wenn eine Optionstaste gleichzeitig mit der Maustaste gedrückt wird, geht das System in die Ziehen-Betriebsart, indem die Variable fInteractionType konstant auf kDrag gestellt wird. Danach beginnt das System, einen Ziehen- Vorgang unter Verwendung des ausgewählten Objektes als Ziel des Vorganges auszuführen; oder
(b) wenn keine Optionstaste gedrückt wurde, geht das System in die Auswahl-Betriebsart, indem die Variable fInteractionType konstant auf kSelect gestellt wird. Danach wird der Auswahlvorgang begonnen.
Wenn ein Anwender bereits die Maustaste gedrückt hatte und weiterhin die Maustaste drückt, wird die folgende Logik angewandt. Wenn sich das System in der Auswahl-Betriebsart befindet, bestimmt das System zuerst, ob der Anwender die Maus über einen gewissen Grenzwert, der auch als Bewegungsgrenzwert bezeichnet wird, bewegt hat. Dies geschieht durch Vergleich der ursprünglichen Mausposition, die vom GetInitialLocation-Verfahren zurückgegeben wird, mit der momentanen Mausposition, die vom GetCurrentLocation-Verfahren zurückgegeben wird. Wenn die Maus über den Bewegungsgrenzwert hinaus bewegt wurde, beendet das System die Auswahl- Betriebsart und geht in die Bewegungs-Betriebsart. Dies geschieht dadurch, indem die Variable fInteractionType konstant auf kMove gesetzt wird. Das System fordert dann das Objekt auf, den Auswahlvorgang durch Aufrufen seines SelectEnd-Verfahrens zu beenden. Das System startet daraufhin einen Bewegungsvorgang durch Aufruf seines MoveBegin- Verfahrens.
Andernfalls überprüft das System, wenn die Maus nicht bewegt wurde, wie lange die Maustaste bereits gedrückt wurde. Dies geschieht durch Vergleich der ursprünglichen Maustastendrückzeit, welche vom GetInitialTime-Verfahren zurückgegeben wird, mit der aktuellen Zeit, welche vom GetCurrentTime-Verfahren zurückgegeben wird. Wenn die Dauer des Maustastendrucks über einem bestimmten Grenzwert liegt, welcher als Spähgrenzwert bezeichnet wird, beendet das System die Auswahl-Betriebsart und geht in die Späh- Betriebsart über. Dies erfolgt durch Einstellen der Variablen fInteractionType konstant auf kPeek. Es ruft das Objekt auf, den Auswahlvorgang durch Aufruf seines SelectEnd- Verfahrens zu beenden und beginnt einen Spähvorgang durch Aufruf seines PeekBegin-Verfahrens. Wenn andernfalls die Maus nicht bewegt wurde oder nicht über einen bestimmten Späh-Grenzwert hinaus niedergedrückt wurde, fährt das System mit dem Auswahlvorgang durch Aufrufen des SelectRepeat-Verfahrens des Befehls fort. Wenn das System erkennt, daß sich ein Anwender in der Bewegungs-Betriebsart befindet, bestimmt das System zuerst, ob der Anwender die Maus innerhalb des Fensters, an der Umrandung des Fensters, oder außerhalb des Fensters bewegt hat. Dies geschieht durch Vergleich der momentanen Mausposition, zurückgegeben vom GetCurrentLocation-Verfahren, mit den Grenzen des Objektbehälters, zurückgegeben von GetContainerBounds.
Wenn sich die Maus noch immer innerhalb der Grenzen des Fensters befindet, fährt das System mit dem Bewegungs- Vorgang durch Aufruf des MoveRepeat-Verfahrens des Objektes fort. Wenn sich die Maus an der Grenze des Fensters befindet, zeigt dies einen AutoScroll-Vorgang an. Das System fordert den Objektbehälter auf, in die von der Mausposition angezeigte Richtung zu rollen. Dies geschieht durch Aufruf des Autoscroll-Verfahrens des Behälters und durch Weitergabe der momentanen Mausposition als Parameter. Nach Beendigung fährt das System mit dem Bewegungs-Vorgang durch Aufruf des MoveRepeat-Verfahrens des Objektes fort.
Wenn sich die Maus außerhalb des Fensters bewegt hat, beendet das System die Bewegungs-Betriebsart und beginnt mit der Ziehen-Betriebsart. Dies geschieht durch Einstellen der Variablen fInteractionType konstant auf kDrag. Es fordert das Objekt auf, den Bewegungs-Vorgang durch Aufrufen seines MoveEnd-Verfahrens zu beenden. Danach fordert es das Objekt auf, durch Aufrufen seines DragBegin-Verfahrens mit dem Ziehen-Vorgang zu beginnen. Wenn sich das System in der Ziehen-Betriebsart befindet, fährt das System durch Aufruf des DragRepeat-Verfahrens des Objektes mit dem Ziehen- Vorgang fort. Wenn sich das System in der Spähen- Betriebsart befindet, bestimmt das System zuerst, ob der Anwender die Maus über einen bestimmten Grenzwert, der als Bewegungs-Grenzwert bezeichnet wird, hinaus bewegt hat. Dies geschieht durch Vergleich der ursprünglichen Mausposition, welche vom GetInitialLocation-Verfahren zurückgegeben wird, mit der momentanen Mausposition, welche vom GetCurrentLocation-Verfahren zurückgegeben wird.
Wenn sich die Maus über den Bewegungs-Grenzwert hinaus bewegt hat, beendet das System die Späh-Betriebsart und beginnt mit der Bewegungs-Betriebsart. Dies geschieht durch Einstellen der Variablen fInteractionType konstant auf kMove. Es fordert das Objekt auf, die Späh-Betriebsart durch Aufruf seines PeekEnd-Verfahrens zu beenden. Es fordert das Objekt auf, durch Aufruf seines Movegin-Verfahrens mit dem Bewegungs-Vorgang zu beginnen. Wenn sich andernfalls die Maus nicht bewegt hat, fährt das System durch Aufruf des PeekRepeat-Verfahrens mit dem Späh-Vorgang fort.
Wenn das System erkennt, daß ein Anwender die Maustaste losläßt, dann beendet das System die Auswahl-Betriebsart, wenn es sich gerade in der Auswahl-Betriebsart befindet. Dies geschieht durch Einstellen der Variablen fInteraction- Type auf konstant kNone. Das System beauftragt das Objekt, den Auswahl-Vorgang durch Aufruf seines SelectEnd-Verfahrens zu beenden. Wenn sich das System in der Bewegungs-Betriebsart befindet, beendet das System die Bewegungs-Betriebsart. Es tut dies durch Einstellen der Variablen fInteractionType auf konstant kNone. Danach beauftragt das System das Objekt, den Bewegungs-Vorgang durch Aufrufen seines MoveEnd-Verfahrens zu beenden, und es beendet die Ziehen-Betriebsart durch Einstellen der Variablen fInteractionType auf konstant kNone. Es fordert das Objekt auf, den Ziehen-Vorgang durch Aufruf seines Dragend-Verfahrens zu beenden. Wenn sich das System in der Späh-Betriebsart befindet, beendet das System die Späh-Betriebsart. Dies geschieht durch Einstellen der Variablen fInteractionType auf konstant kNone. Es fordert das Objekt auf, die Späh-Betriebsart durch Aufruf seines PeekEnd-Verfahrens zu beenden.
Dementsprechend ist es eine Hauptaufgabe der vorliegenden Erfindung, ein neuartiges Hardware- und Softwaresystem zu schaffen, welches es möglich macht, die Inhalte eines Fensters dynamisch zu aktualisieren, wenn ein Anwender einen Bildlaufleistendaumen bewegt. Das System erkennt, wenn ein Anwender auf einen Bildlaufleistendaumen drückt. Wenn der Anwender auf einen Bildlaufleistendaumen drückt, beginnt das System mit der Initiierung eines Bildlaufbefehles, um den Abschnitt der Daten, die in einem Fenster freiliegen, zu ändern. Ein Befehl ist ein Objekt, das eine Endanwendermaßnahme wie zum Beispiel einen Bildlaufvorgang implementiert. Ein Bildlaufbefehl verfügt über einen Parameter, die Position, zu der die Inhaltsansicht gerollt werden soll. Das System stellt diese Position auf die aktuelle Bildlaufposition ein. Dies geschieht durch Aufruf SetScrollposition des Befehls und durch Einstellen des Bildlaufs, um auf jenen Wert zu positionieren, der vom GetScrollPosition- Verfahren der Bildlaufleiste zurückgegeben wird.
Wenn ein Anwender die Maus innerhalb der Bildlaufleiste bewegt, fährt das System mit der Ausführung des Bildlaufbefehls fort, um dynamisch den Abschnitt der im Fenster freiliegenden Daten zu ändern. Das System stellt die Bildlaufposition des Befehls auf die neue Bildlaufposition ein. Dies geschieht durch Aufruf der Setscrollposition des Befehls und durch Einstellen des Wertes entsprechend dem Wert, der vom GetScrollPosition-Verfahren der Bildlaufleiste zurückgegeben wird. Die Ausführung des Befehls wird dann bei Aufruf des DoRepeat-Verfahrens wiederholt. Dadurch rollt die Inhaltsansicht zur neuen Position. Diese Verarbeitung wird fortgesetzt, solange ein Anwender die Maustaste gedrückt hält.
Wenn ein Anwender die Maustaste losläßt, beendet das System die Ausführung des Bildlaufbefehls, um dynamisch den Abschnitt der im Fenster freiliegenden Daten zu ändern. Das System stellt die Bildlaufposition des Befehls auf die endgültige Bildlaufposition ein. Dieser Vorgang wird durch Aufruf der SetScrollPosition des Befehls und durch Einstellen auf den gleichen Wert, der vom Getscrollposition-Verfahren der Bildlaufleiste zurückgegeben wird, erreicht.
Figur 20 ist ein Flußdiagramm, das die detaillierte Logik im Zusammenhang mit dem Bildlaufvorgang gemäß der vorliegenden Erfindung darstellt. Die Verarbeitung beginnt beim Punkt 2000 und wird sofort an den Funktionsblock 2010 weitergegeben, wo die aktuelle Bildlaufposition auf der Basis der aktuellen Cursorposition initialisiert wird. Danach wird am Entscheidungsblock 2020 eine Überprüfung durchgeführt, um zu erkennen, ob der Bildlaufdaumen ausgewählt wurde. Ein Beispiel eines Bildlaufdaumens ist in Figur 21A bei der Beschriftung 2110 dargestellt. Wenn der Bildlaufdaumen ausgewählt wurde, geht die Kontrolle zum Entscheidungsblock 2030 weiter, um zu bestimmen, ob der Bildlaufdaumen bewegt wurde. Wenn dies der Fall ist, wird die Bildlaufposition auf die neue Position des Bildlaufdaumens eingestellt, und die Anzeige wird neu formatiert, um den sofortigen Bildlaufvorgang zu reflektieren und für den Anwender darzustellen. Wenn sich der Bildlaufdaumen nicht bewegt hat, wird eine weitere Überprüfung am Entscheidungsblock 2050 durchgeführt, um zu bestimmen, ob der Bildlaufdaumen losgelassen wurde. Wenn nicht, wird die Kontrolle zum Entscheidungsblock 2030 zurückgegeben. Wenn der Bildlaufdaumen losgelassen wurde, geht die Kontrolle weiter zum Funktionsblock 2060, um den Bildlauf-Vorgang zu beenden und das System zu einem Nicht-Bildlaufbetriebszustand zurückzuführen, und die Verarbeitung wird am Endpunkt 2070 beendet.
Figur 21A, 21B und 21C zeigen einen Fenster-Bildlauf gemäß der vorliegenden Erfindung. In Figur 21A befindet sich der Rollbalkendaumen 2110 am oberen Ende des Fensters 2112. Figur 218 zeigt den Bildlaufdaumen 2120, der zur Mitte des Fensters bewegt wurde, sowie den entsprechend aktualisierten Inhalt des Fensters 2122. Figur 21C zeigt den Bildlaufdaumen 2140, der zum unteren Rand des Fensters bewegt wurde, und den untersten Abschnitt des Fensters 2142, der dargestellt ist.

Zusammenarbeitslogik

Zusammenarbeit beginnt beim Starten des Modelldienstleisters durch Aufruf eines Prozesses. Zum Beispiel ruft das Doppelklicken eines Anwenders auf ein Dokument den Taskinitiierungsabschnitt des Betriebssystems auf. Dieser Aufruf erzeugt einen Task. Der Task wird von einem TTaskprogram- Objekt erzeugt, das die zur Erzeugung des neuen Tasks benötigten Informationen einkapselt. Figur 22 zeigt die Klassenhierarchie für die Taskverwaltung gemäß der vorliegenden Erfindung. Das detaillierte Design der einzelnen in Figur 22 dargestellten Blöcke wird unten dargestellt.

Taskverwaltung

Figur 23 stellt das Verfahren zur Erzeugung eines Haupttasks an einem anderen Team durch TTeamHandle dar. TTaskProgramm-Objekte verwenden die Schnittstelle auf TTeamHandle zur Erzeugung eines neuen Teams. Nehmen wir an, wir möchten, daß ein neues Team die Befehlszeile "runtest - t MainTimeMediaTest -1 TimeMediaTest" ausführt. Wir geben diesen Text in den Konstruktor für TCommandLine ein. Der TTeamHandle-Konstruktor glättet die TCommandLine und strömt sie zum Knopfdienstleister-Task am Zielteam. Am Zielteam läßt der Knopfdienstleister die TCommandLine wieder aufleben und verwendet die von der TTaskProgram-Klasse definierte abstrakte Schnittstelle, um die Ausführung des "runtest"-Programms vorzubereiten. Das Initialisierungsverfahren sucht die ausführbare "runtest"-Bibliothek, ladet diese Bibliothek sowie jene, die es benötigt, ein und erhält die Adresse von "main". Das Startverfahren (Run-Verfahren) ruft "main" auf.
Die Flußkontrolle ist in zwei getrennte Verfahren unterteilt, nämlich Initialisieren (Initialize) und Starten (Run). Das Initialisieren-Verfahren führt alle Arbeiten aus, die zur Vorbereitung des Anwendercodes für die Ausführung notwendig sind. Im Falle der TCommandLine-Unterklasse umfaßt dies alle Schritte bis zu und einschließlich des Ladens der benötigten Bibliotheken und Findens der Adresse des "main"-Eintrittspunktes. Wenn das Initialisieren-Verfahren zurückkehrt, wird der als TTeamHandle-Konstruktor bezeichnete Task ungeblockt. In anderen Worten, der Konstruktor am erzeugenden Team ist synchron mit dem Initialisieren-Verfahren im neuen Task am Zielteam. Der erzeugende Task erhält eine Bestätigung, daß seine Maßnahme erfolgreich war, bis zum Punkt des Eintritts des "user code" (Anwendercode), wie zum Beispiel ein "main (argc, argv)"- Eintrittspunkt. Der erzeugende Task kann zum Beispiel getrost davon ausgehen, daß Bibliotheken geladen wurden, daß er zu Eintrittspunktadressen springen kann, daß statistische Daten initialisiert wurden, und daß er Meldungen senden kann.
Zum zweiten schafft das Definieren von getrennten Initialisieren- und Starten-Verfahren ein Ausnahmemodell, das zwischen Ttaskprogram-Ausnahmen und Klientencodeausnahmen unterscheidet. Wenn zum Beispiel eine Ausnahme im Initialisieren-Verfahren auftritt, verursachen wir das Auftreten einer Ausnahme im Konstruktor, was dem erzeugenden Team mitteilt, daß die Maßnahme erfolglos war. Dies könnte auftreten, wenn das Initialisieren-Verfahren nicht in der Lage ist, einige benötigte Bibliotheken zu finden, zu laden oder zu initialisieren. Wenn eine Ausnahme im Starten-Verfahren auftritt, dann spiegelt dieses Ereignis eine nichtbehandelte Ausnahme im Klientencode wieder. Eine Ausnahme, die während des Starten-Verfahrens auftritt, kann zusätzlich je nach Bedarf mitteilen oder aufzeichnen.

Zusätzliche Synchronisierung

Manchmal können bestimmte Unterklassen von TTaskProgram über Klienten verfügen, die eine Synchronisierung erfordem, die über das einfache "Blocken, bis Initialisieren zurückkehrt"-Modell hinausgeht. Nehmen wir an, der Erzeuger eines Tasks muß sich mit dem Zieltask synchronisieren, nachdem der Zieltask einen bekannten Zustand erlangt. Ein einfaches Protokoll ist hier beschrieben. Der Erzeuger gibt einen Austausch in das Ttaskprogram weiter, an dem er oder eine andere Einheit später einen Empfang durchführen wird. Nachdem der Zieltask einen zuvor angeordneten Zustand erreicht hat, führt er einen Sendevorgang zum Austausch durch, zu dem er gegeben wurde. Die Antwort deblockiert den Zieltask, der weiß, daß der erzeugende Task (oder eine andere Einheit, welche den Austausch kennt) die Erlangung des zuvor angeordneten Zustandes des Tasks anerkannt hat.
Figur 24 ist ein Flußdiagramm der detaillierten Logik gemäß der vorliegenden Erfindung. Die Verarbeitung beginnt beim Block 2400, der sofort die Kontrolle an den Funktionsblock 2410 weitergibt, wo ein Anwender auf ein Dokumentobjekt doppelgeklickt hat. Dann, am Funktionsblock 2420, erzeugt das Taskprogramm einen neuen Adreßplatz und fügt ein Objekt in den Adreßplatz ein und verursacht die Erzeugung eines Tasks im Adreßplatz und beginnt ein Verfahrens des Objektes. Das Objekt öffnet eine Dokumentdatei und läßt ein Dokumentobjekt wieder aufleben und ruft ein Startverfahren für das Objekt auf, wie dies im Funktionsblock 2430 dargestellt ist. Das Verfahren prüft zuerst, um zu sehen, ob ein Modelldienstleister für das Dokument aktiv ist. Dann, wenn kein Modelldienstleister aktiv ist, erzeugt das Verfahren einen Modelldienstleister und initiiert ihn, wie dies im Funktionsblock 2440 dargestellt ist, liest das Dokument ein und öffnet die mit dem Dokument im Zusammenhang stehende Anwenderschnittstelle, wie dies im Funktionsblock 2450 dargestellt ist. Der Anwender kann danach Befehle eingeben. Wenn es hier einen Modelldienstleister gibt, dann stellt das Verfahren eine Verbindung zum bestehenden Modelldienstleister her, lädt eine Kopie des Dokumentes vom Modelldienstleister, öffnet die Anwenderschnittstelle, und der Anwender kann danach Befehle eingeben.
Es gibt zwei grundlegende Arten von Befehlen, einen nichtwiederholenden Befehl und einen wiederholenden Befehl. Nichtwiederholende Befehle führen ihre Maßnahmen als einen einzigen atomischen Vorgang aus. Wiederholende Befehle haben eine Beginnphase, null oder mehrere kontinuierliche Phasen und eine Endphase. Für manche Befehle können einige der kontinuierlichen Phasen übersprungen werden, ohne daß dadurch des Ergebnis des Befehls beeinflußt wird. Bei den nichtwiederholenden Befehlen überprüft der Verfolger, der aufgerufen wird, wenn ein Anwender eine Maßnahme setzt, die Anwendermaßnahme, wie dies im Funktionsblock 2460 dargestellt ist, um zu bestimmen, welchen Befehl der Anwender ausgeben möchte, und führt das Tun-Verfahren des Befehls aus. Wenn zum Beispiel ein Anwender auf ein Bildsymbol doppelklickt, wird der Öffnen-Befehl für das Bildsymbol ausgegeben, auf welches doppelgeklickt wurde.
Das Tun-Verfahren des Befehls überträgt den Befehl zum Modellbefehlsversender. Der Modellbefehlsversender (MCD) empfängt Befehle und verteilt Befehle zum Modelldienstleister, wie dies im Funktionsblock 2470 dargestellt ist. Der Modelldienstleister ist ein Objekt, das für die Erhaltung der Liste der Mitarbeiter zuständig ist, der entscheidet, welcher Mitarbeiter die Autorität hat, das Modell zu ändern, und der die Befehle an alle aktiven Mitarbeiter verteilt, wie dies im Funktionsblock 2480 dargestellt ist.
Wenn der Modelldienstleister einen Befehl empfängt, bestimmt er, ob der Mitarbeiter, der den Befehl sendet, die Erlaubnis hat, einen Befehl auszugeben. Wenn dies nicht der Fall ist, wird ein Fehler zurückgegeben. Wenn der Befehl erlaubt ist, wird der Befehl an die Modellbefehlsausführung aller anderen aktiven Mitarbeiter gesandt, und der Befehl wird zum Modellbefehlsversender des sendenden Mitarbeiters zurückgegeben. Der Modellbefehlsversender speichert den zurückgegebenen Befehl wieder im ursprünglichen Befehl und führt dann das "handle-do-Verfahren" (Bearbeiten-Tun-Verfahren) des Befehls aus. Dieses Verfahren verändert das Modell auf der Basis des Befehls. Das Modell erzeugt eine Meldung, die durch das Meldungsrahmenwerk an alle interessierten Ansichten verteilt wird. Die Ansichten empfangen die Meldung, überprüfen die Meldung und das Modell, um eine momentane Ansicht des Modells darzustellen. Wenn zum Beispiel ein Doppelklick-Befehl auf ein Objekt das ausgewählte Objekt ROT gemacht hätte, dann würde die Ansicht das Objekt als ROTES Objekt neu zeichnen, als auf ihm doppelgeklickt wurde. Dann würde eine grafische Ansicht das Objekt als ein Objekt mit roter Farbe neu zeichnen. Eine Nur-Text-Darstellung hingegen würde die Beschriftung ROT unter das Objekt stellen. Nachdem eine Meldung erzeugt ist, kehrt die Kontrolle zum Versender zurück, der die Kontrolle zum Verfolger zurückgibt.
Wenn die Modellbefehlsausführung eines Mitarbeiters einen Befehl vom Modelldienstleister empfängt, ruft er das "handle-do-Verfahren" (Bearbeiten-Tun-Verfahren) des Befehls auf. Dieses Verfahren verändert das Modell auf der Basis des Befehls. Das Modell erzeugt eine Meldung, welche vom Meldungsrahmenwerk an alle interessierten Ansichten verteilt wird. Die Ansichten empfangen die Meldung, überprüfen die Meldung und das Modell, um eine momentane Ansicht des Modells darzustellen. Wenn zum Beispiel ein Doppelklick-Befehl auf ein Objekt das ausgewählte Objekt ROT gemacht hätte, dann würde die Ansicht das Objekt als ROTES Objekt neu zeichnen, als auf ihm doppelgeklickt wurde. Dann würde eine grafische Ansicht das Objekt als ein Objekt mit roter Farbe neu zeichnen. Eine Nur-Text-Darstellung hingegen würde die Beschriftung ROT unter das Objekt stellen. Nachdem eine Meldung erzeugt ist, kehrt die Kontrolle zum Modellbefehlsausführer zurück, um auf einen weiteren Befehl zu warten.

Modellbasierte Verfolgungseinzelheiten

Einleitung

Einfache Verfolgung

Figur 25 ist ein Diagramm einer typischen Verfolgungsschleife, wie sie in Systemen des Standes der Technik, wie zum Beispiel dem Apple Macintosh, verwendet wird. Diese Schleife ermöglicht es einem Anwender, mit einem Computer mit Hilfe der Maus und dem Bildschirm zu interagieren.

Probleme bei der einfachen Verfolgung

Die einfache Verfolgung arbeitet gut bei einigen Arten der Anwenderinteraktion, aber ihre Anwendung in der Dokumentenarchitektur ist schwierig. Die Dokumentenarchitektur ermöglicht es mehreren Ansichten derselben Daten, auf mehreren Maschinen ansässig zu sein. Es wäre unbeholfen, von jedem einzelnen Verfolger zu verlangen, daß er weiß, wie eine Rückmeldung in jede mögliche Art von Ansicht auf jeder möglichen Maschine eines Mitarbeiters gezeichnet werden muß.

Abstrakte Verfolger und Rückmelder

Abstrakte Verfolger waren die ersten Versuche, eine Verfolgung in mehreren Ansichten und über mehrere Maschinen hinweg zu unterstützen. Wenn die Verfolgung beginnt, werden ein abstrakter Verfolger und eine Anzahl an Rückmeldern erzeugt. Ein Rückmelder wird für jede Ansicht auf jeder Maschine erzeugt. Der abstrakte Verfolger wandelt die konkreten, gerätebasierten Ereignisse in abstrakte, modellbasierte Ereignisse um. Die Modellereignisse werden an die verschiedenen Rückmelder verteilt, wo sie verwendet werden, um Rückmeldungen zu den Ansichten zu schaffen. Figur 26 zeigt ein Beispiel einer abstrakten Verfolgerschleife. Abstrakte Verfolger ermöglichen Mitarbeiter- und Mehransichten-Verfolgung, aber es gibt hierbei Probleme:
Die Rückmelder verdoppeln schließlich den Darstellungscode, der bereits in den Ansichten implementiert ist.
Der Rückmelder gibt nur vor, das Modell inkrementell zu verändern. Bei komplexen Modellen, wie zum Beispiel Texteditoren und rückhaltebasierten 3D-Grafikeditoren, könnte der Rückmelder nicht in der Lage sein, die Auswirkungen der Anwendereingaben adäquat zu simulieren.

Modellbasierte Verfolgung

Wenn der Verfolger das Modell tatsächlich verändern würde, wäre alles viel einfacher. Und genau das geschieht in der modellbasierten Verfolgungsschleife. Der Verfolger gibt Befehle an das Modell aus, welches Änderungsmeldungen an alle interessierten Ansichten schickt, wie dies in Figur 27 dargestellt ist. Der Code in der Sprache C, der verwendet wird, um den Verfolger zu implementieren, wird unten dargestellt:

Befehle

Die Aufgabe des Befehls ist es, das Modell schrittweise zu verändern. Anstatt nur einmal ausgeführt zu werden, wird der Befehl inkrementell ausgeführt. Zusätzlich dazu, daß er einmal geströmt wird, wird der Befehl mit Kommandodeltaobjekten aktualisiert. Es gibt hier zwei Gruppen von Verfahren, die zur Aktualisierung des Befehls verwendet werden. Deren Aufruffolgen sind unten dargestellt:
Die Regel für das Schreiben eines StreamOut... Delta- Verfahrens besteht darin, alle Daten auszuströmen, die sich während dieser Verfolgungsphase geändert haben.
Boolean TMyCommand: :StreamOutContinueDelta (Tstream& towhere) const
Das StreamOutContinueDelta-Verfahren gibt TRUE (WAHR) zurück, wenn dieses Delta erfordert wird. Einige Verfolger, wie zum Beispiel ein Gummibandlinien-Verfolger, können beliebige oder alle ihrer Zwischenschritte überspringen. Diese Art von Verfolgern sollte immer FALSE (FALSCH) von StreamOutContinueDelta zurückgeben. Andere Arten von Verfolgern, wie zum Beispiel ein vieleckiger Skizzierverfolger, könnte FALSE während des Ziehen-Abschnittes einer Verfolgung zurückgeben, aber jedesmal TRUE, wenn ein Vertex angeklickt wird.
Die Regel zum Schreiben eines StreamIn...Delta-Verfahrens besteht darin, die Daten einzuströmen, die vom entsprechenden StreamOut...Delta-Verfahren ausgeströmt wurden: void Tmycommand::StreamInContinueDelta (Tstream& .fromWhere)
Aufgrund dieser Standard-Verfahren können die operator»= und operator«= - Verfahren außer Kraft gesetzt werden, um das Strömen für alle drei Verfolgungsphasen durchzuführen. Wenn der Verfolger TModel::ProcessDoFirstTime() aufruft, wird das Befehlsargument geglättet und zum Modelldienstleister gesandt. Von dort wird es wiederum geglättet und zu den einzelnen im schnellen Pufferspeicher befindlichen Modellen gesandt. Bei jedem einzelnen Modell wird das Handle- DoFirst()-Verfahren des Befehls ausgeführt.
Wenn der Verfolger TModel::ProcessDoContinue() aufruft, wird das Befehlsargument aufgefordert, die Deltainformationen auszuströmen Das Befehlsdelta wird zum Modelldienstleister gesandt. Von da wird das Delta zu den einzelnen im schnellen Pufferspeicher befindlichen Modellen gesandt. Bei jedem einzelnen Modell wird das Delta in die lokale Kopie des Befehls geströmt Danach wird das HandleDoContinue()- Verfahren des Befehls ausgeführt.
Wenn der Verfolger TModel::ProcessDoLastTime() aufruft, wird das Befehlsargument aufgefordert, die Deltainformationen auszuströmen Das Befehlsdelta wird zum Modelldienstleister gesandt. Von hier wird das Delta zu den einzelnen im schnellen Pufferspeicher befindlichen Modellen gesandt. Bei jedem einzelnen Modell wird das Delta in die lokale Kopie des Befehls geströmt Danach wird das HandleDoLastTime()-Verfahren des Befehls ausgeführt.
Es gibt zwei Arten, wie ein inkrementeller Befehl seine erweiterte Do-Phase beenden kann. Die standardmäßige Art besteht im Aufruf von TModel::ProcessDoLastTime (). Die andere Art besteht darin, daß der Mitarbeiter, der die Verfolgung durchführt, unerwarteterweise die Zusammenarbeit beendet. In diesem Fall wird das HandlecollaboratorDied()-Verfahren des Befehls am Modelldienstleister aufgerufen.
Nachdem die erweiterte Do-Phase beendet ist, sollte sich der Befehl im selben Zustand befinden, als ob sein Handle- Do()-Verfahren aufgerufen worden wäre. Der Befehl am Modelldienstleister wird zum Zwecke von Aufzeichnungen und Rückgängigmachen an den Befehlsverwalter weitergegeben. Die Befehle an den im schnellen Pufferspeicher befindlichen Modellen werden gelöscht.
Standardmäßig werden die Befehle zum Modelldienstleister gesandt, bevor sie an lokalen, im schnellen Pufferspeicher befindlichen Modellen angewandt werden. Dadurch erhält das HandleModelServerDo()-Verfahren eine Möglichkeit, mit dem Modelldienstleister zu interagieren. Während dadurch die Implementierung einiger Arten von Befehlen (wie zum Beispiel Ausschneiden & Einfügen, und Objekterzeugungsbefehle) wesentlich erleichtert wird, verlangsamt dies die Umlaufverzögerung der meisten Verfolgungsbefehle ohne Grund.
Wenn Ihr Befehl nicht vom Zustand des Modelldienstleisters abhängig ist, können Sie die lokale Ausführung des Befehls durch Außerkraftsetzen von AllowsEarlyDo und die Zurückgabe von TRUE beschleunigen. Dadurch wird es für die Dokumentarchitektur möglich, Ihren Befehl sofort auszuführen, bevor er zum Modelldienstleister geführt wird. virtual Boolean AllowsEarlyDo() const:
AllowsEarlyDo wird jedesmal überprüft, wenn ein Befehl ausgeführt wird, einschließlich der Continue- und Last-Time- Phasen der Verfolgung. Es ist möglich, jedesmal eine andere Antwort zurückzugeben, wenn dieses Verfahren aufgerufen wird.
Einige Befehle verfügen über keine gut festgelegten Beendigungsbedingungen. Die Texteingabeverfolgung endet zum Beispiel erst, wenn ein anderer Befehl gestartet wird. Um diese Arten von Befehlen zu unterstützen, beendet das Modell wartende inkrementelle Befehle automatisch, wenn ein anderer Befehl verarbeitet wird. Das Modell tut dies, indem es das Tcommand::FinishTracking-Verfahren des aktuellen Verfolgungsbefehles aufruft.
Virtual void Tcommand::Finishtracking ();
Das standardmäßige Verhalten von Finishtracking ist ungefähr folgendermaßen:
Es sei darauf hingewiesen, daß sich die meisten Verfolger (und ihre Befehle) selbst löschen, wenn das StopTracking- Verfahren aufgerufen wird. Dies bedeutet, daß Sie sich auf keine Ihrer Fallvariablen beziehen (oder irgendwelche virtuellen Verfahren aufrufen) sollten, nachdem StopTracking aufgerufen wurde.
Um dieses Verhalten zu unterstützen, müssen Sie dem Verfolgungsbefehl Informationen bezüglich seinem Verfolger durch Aufruf des Setracker-Verfahrens mitteilen. SetTracker kann entweder während der Konstruktion des Befehls oder jederzeit vor der ersten Ausführung des Befehls durch den Verfolger angefordert werden.

Modelle

Die Aufgabe des Modells besteht darin, ein Verwahrungsort für Daten zu sein und Änderungsmeldungen zu veröffentlichen, wenn die Daten verändert werden. Das Änderungsereignis sollte ausreichend Informationen über die Änderung enthalten, damit sich die Ansicht auf intelligente Weise selbst aktualisieren kann. Dies umfaßt für gewöhnlich den alten Wert der Auswahl, wie er vor der Änderung vorhanden war. Herkömmlicherweise wird die Änderungsmeldung gesendet, nachdem die Daten geändert wurden.

Ansichten

Die Aufgabe der Ansicht besteht darin, die Daten im Modell darzustellen und rasch auf Änderungsmeldungen zu reagieren. Wenn die Daten rasch genug aktualisiert werden können, dann besteht eine der einfachsten Reaktionen auf eine Änderungsmeldung in einem TView::InvalidateAll(). Für normale Ansichten wird es erforderlich sein, die Ansicht mit der Möglichkeit einer raschen Reaktion auf Modelländerungsmeldungen hin zu konstruieren. Dies ist nicht so schwer, wie es klingen mag. Ein gutes Design zum Zeichnen von Programmen würde zwei bildschirmferne Puffer verwenden. Der erste Puffer würde all die unausgewählten Objekte enthalten. Der zweite Puffer würde verwendet werden, um die ausgewählten Objekte über die unausgewählten Objekte zu stellen. Danach würde der zweite Puffer verwendet werden, um den Bildschirm zu aktualisieren.

Claims

1. Eine Vorrichtung (10-38) zur gleichzeitigen Rahmenwerk-verarbeitung (2480) zwischen einem ersten Benutzer (2460) einer Anwendung in einem ersten Computer (10) mit einem ersten im Multiprogramm-Betrieb arbeitenden, objekt-orientierten Betriebssystem und einer durch das erste objekt-orientierte Betriebssystem gesteuerten ersten Anwendung, der über ein Datennetz (34) mit einem zweiten Benutzer (2460) einer Anwendung aut einem zweiten Computer (10) mit einem zweiten im Multiprogramm-Betrieb arbeitenden, objekt-orientierten Betriebssystem verbunden ist und einer zweiten Anwendung, die durch das zweite objekt-orientierte Betriebssystem gesteuert wird, gekennzeichnet durch:

(a) Mittel zur Analyse eines ersten Benutzerbefehls in einem ersten Computersystem mit einem ersten im Multiprogramm-Betrieb arbeitenden, objekt-orientierten Betriebssystem (2460):

(b) Dienstleistungsmittel zur Übertragung des ersten Benutzerbelehls zu einem ersten Modellobjekt im ersten Computersystem und zu einem zweiten Modellobjekt im zweiten Computersystem (2470):

(c) erste Modellobjekt-Mittel zur Meldung (1860-1870) an wenigstens den ersten Benutzer des ersten Benutzerbefehls im ersten computersystem:

(d) zweite Modellobjekt-Mittel zur Meldung (1860-1870) an wenigstens den zweiten Benutzer des ersten Benutzerbefehls im zweiten Computersystem:

(e) Mittel zur gleichzeitigen Ausführung des ersten Benutzerbefehls in der durch das erste objektorientierte Betriebssystem gesteuerten ersten Anwendung im ersten Computer und in der durch das zweite objekt-orientierte Betriebssystem gesteuerten zweite Anwendung im zweiten Computer (2480).

2. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 1 angegeben enthaltend Verarbeitungsmittel, um nur einem Benutzer die Eingabe von Befehlen zu gestatten (2460).

3. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 1 angegeben enthaltend Verarbeitungsmittel zur Analyse von Befehlen von mehr als zwei Benutzern (2460-2480 (Figur 27)).

4. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 1 angegeben, worin der erste Benutzerbefehl ein Textverarbeitungsbefehl ist (600-640).

5. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 1 angegeben, worin der erste Benutzerbefehl ein Graphik-Befehl oder ein Bildverarbeitungsbefehl ist (900-930).

6. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 1 angegeben, worin der erste Benutzerbefehl ein Multimediabefehl ist (800-806).

7. Eine Vorrichtung zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 4 angegeben, enthaltend Verarbeitungsmittel zum Einfangen nichtautorisierter Benutzerbefehle (1400-1470).

8. Ein Verfahren zur gleichzeitigen Rahmenwerk-Verarbeitung (2480) zwischen einem ersten Benutzer (2460) einer Anwendung in einem ersten Computer (10) mit einem ersten im Multiprogramm-Betrieb arbeitenden objekt-orientierten Betriebssystem und einer durch das erste objekt-orientierte Betriebssystem gesteuerten ersten Anwendung, der über ein Datennetz (34) mit einem Zweiten Benutzer (2460) einer Anwendung auf einem zweiten Computer (10) mit einem zweiten im Multiprogramm-Betrieb arbeitenden, objekt-orientierten Betriebssystem verbunden ist, und einer zweiten Anwendung, die durch das zweite objekt-orientierte Betriebssystem gesteuert wird, gekennzeichnet durch die Schritte:

(a) Analyse eines ersten Benutzerbefehls in einem ersten Computersystem mit einem ersten im Multiprogramm-Betrieb arbeitenden, objekt-orientierten Betriebssystem (2460):

(b) Übertragung des ersten Benutzerbefehls zu einem ersten Modellobjekt im ersten Computersystem und zu einem zweiten Modellobjekt im zweiten Computersystem (2470):

(c) Meldung an wenigstens den ersten Benutzer des ersten Benutzerbefehls im ersten Computersystem der das erste Modellobjekt benutzt (1860-1870):

(d) Meldung an wenigstens den zweiten Benutzer des ersten Benutzerbefehls im zweiten Computersystem, der das erste Modellobjekt benutzt (1860-1870):

(e) gleichzeitige Ausführung des ersten Benutzerbefehls in der durch das erste objekt-orientierte Betriebssystem gesteuerten ersten Anwendung im ersten Computer und in der durch das zweite objekt-orientierte Betriebssystem gesteuerten zweite Anwendung im zweiten Computer (2480).

9. Ein Verfahren zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 8 angegeben, enthaltend den Schritt, nur einem Benutzer die Eingabe von Befehlen zu gestatten (2460).

10. Ein Verfahren zur gleichzeitigen Rahmenwerk-verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 8 angegeben, enthaltend den Schritt der Analyse von Befehlen von mehr als zwei Benutzern (2460-2480 (Figur 27)).

11. Ein Verfahren zur gleichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 8 angegeben, worin der erste Benutzerbefehl ein Textverarbeitungsbefehl ist (600-640).

12. Ein Verfahren zur geichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 8 angegeben, worin der erste Benutzerbefehl ein Graphik-Befehl oder ein Bildverarbeitungsbefehl ist (900-930).

13. Ein Verfahren zur gleichzetigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 8 angegeben, worin der erste Benutzerbefehl ein Multimediabefehl ist (800-806).

14. Ein Verfahren zur geichzeitigen Rahmenwerk-Verarbeitung zwischen wenigstens zwei Benutzern einer Anwendung, wie in Anspruch 11 angegeben, enhaltend den Schritt, nichtautorisierter Benutzerbefehle einzufangen (1400-1470).