DE69518238T2

DE69518238T2 - Objekt für die definition einer dialogeinheitschnittstelle

Info

Publication number: DE69518238T2
Application number: DE69518238T
Authority: DE
Inventors: K. Cirne
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1994-05-16
Filing date: 1995-05-16
Publication date: 2001-03-29
Anticipated expiration: 2015-05-17
Also published as: EP0760124B1; AU2551895A; WO1995031772A1; US20040006649A1; DE69518238D1; EP0760124A1; US7712109B2

Description

BEGRENZTE VERZICHTERKLÄRUNG AUF DAS URHEBERRECHT

Ein Teil der Offenbarung dieses Patentdokuments enthält Material, das dem Urheberrechtsschutz unterliegt. Der Eigentümer des Urheberschutzrechts hat keine Einwände gegen die Faksimile-Wiedergabe des Patentdokuments oder der Patentoffenbarung, wie sie in der Patentrolle oder den Aufzeichnungen des amerikanischen Patent- und Warenzeichenamts (U. S. Patent and Trademark Office) erscheint, behält sich jedoch anderweitig alle Urheberrechte vor.

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die vorliegende Erfindung betrifft ein System zum Definieren, Verwenden und speziellen Einrichten von Positionen in einem Dialogkästchen.

Beschreibung des Stands der Technik

Bei vielen Computern wird eine Fensterumgebung verwendet. Ein Fenster ist ein Element der Benutzerschnittstelle, das einen Bereich auf dem Bildschirm begrenzt, in dem ein Benutzer Informationen eingeben und betrachten kann.
Softwareanwendungen mit einer Benutzerschnittstelle können Fenster zum Kommunizieren mit dem Benutzer verwenden. Eine Softwareanwendung (oder einfach eine "Anwendung") ist eine Computersoftware, die eine bestimmte Aufgabe ausführt führt. Jedes Informationsteil, das eine Anwendung einem Benutzer darbieten muß, kann in einem Fenster angezeigt werden. In ähnlicher Weise kann jedes Informationsteil, das eine Anwendung von einem Benutzer anfordern muß, erhalten werden, indem der Benutzer in einem Fenster aufgefordert wird, geeignete Aktionen auszuführen. Geeignete Aktionen bedeutet, daß der Benutzer Informationen eintippt, Informationen editiert, ein Kästchen anwählt oder eine Maus verwendet, um eine Taste oder ein Bildzeichen anzuklicken.
Es kann mindestens zwei allgemeine Arten von Fenstern geben, nämlich Dokumentfenster und Dialogkästchen. Dokumentfenster werden in erster Linie verwendet, um es dem Benutzer zu ermöglichen, Informationen, wie Text, Graphik oder andere Daten, einzugeben und zu manipulieren. Häufig, jedoch nicht immer, können die Informationen in einem Dokumentfenster in einer Datei gespeichert werden, aus der der Benutzer die Informationen später wiedergewinnen kann.
Das Dialogkästchen ist ein Fenster, das für einen speziellen, begrenzten Zweck verwendet wird. Im einfachsten Fall kann ein Dialogkästchen verwendet werden, um dem Benutzer Informationen zu zeigen. Die Informationen können eine Mitteilung über einen Fehler, ein Gruß oder ein Fortschrittsbalken, der zeigt, welcher Prozentsatz einer Operation abgeschlossen worden ist, sein. Ein Dialogkästchen ist gewöhnlich ein Pop-out-Fenster, das eine Anwendung verwendet, um Informationen zu zeigen oder anzufordern. In manchen Fällen sind die Informationen zum Abschließen eines Befehls erforderlich. Dialogkästchen können dem Benutzer Informationen zeigen, es dem Benutzer ermöglichen, Informationen zu ändern und es dem Benutzer ermöglichen, weitere Informationen einzugeben. Ein Dialogkästchen kann eine oder mehrere Positionen enthalten, mit denen der Benutzer Text eintippen kann, Optionen auswählen kann oder die Aktion eines bestimmten Befehls lenken kann. Die Positionen sind unter anderem eine Taste, ein Anwählkästchen, editierbarer Text, eine Hilfsposition, ein Bildzeichen, ein Bild, eine Funktaste und statischer Text. Die oben angeführten Positionen sind vordefinierte Positionen. Ein Anwendungsentwickler kann auch benutzerdefinierte oder speziell eingerichtete Positionen erzeugen.
In Fig. 1 ist ein Dialogkästchen 10 dargestellt, das als Teil einer Anwendung zum Zeichnen von Venn-Diagrammen verwendet werden kann. Das Dialogkästchen 10 weist verschiedene Positionen auf. Beispielsweise weist das Dialogkästchen 10 eine Taste 12 ("Speicher die aktuellen Vorlieben") auf. Falls der Benutzer die Taste 12 anklickt, speichert die Anwendung alle Auswahlen, die der Benutzer im Dialogkästchen vorgenommen hat. Der Begriff "klicken" ist so definiert, daß er die Handlung des Benutzers, eine Maus zu verwenden, den Cursor über der Taste anzuordnen und eine Taste auf der Maus herunterzudrücken, einschließt. Die Maus kann durch eine andere Vorrichtung zum Positionieren des Cursors ersetzt werden. Das Dialogkästchen 10 weist auch vier Anwählkästchen 14, 16, 18, 20 auf, denen allen statischer Text zugeordnet ist. Beispielsweise weist das Anwählkästchen 14 den statischen Text "Gib Subjekten existentielle Bedeutung" auf. Bei einer alternativen Ausführungsform kann jeder der statischen Texte als eine separate Position angesehen werden. Während das Dialogkästchen auf einem Bildschirm aktiv ist, kann der Benutzer das Anwählkästchen anklicken. Durch Anklicken des zugeordneten Anwählkästchens (14, 16, 18 und 20) wird das Anwählkästchen zwischen gewählten und nicht gewählten Zuständen umgeschal tet. Wenn der Benutzer die Taste 12 anklickt, werden die aus den Anwählkästchen 14, 16, 18 und 20 ausgewählten Merkmale gespeichert und von der Anwendung beim Erzeugen des Venn-Diagramms verwendet.
Das Dialogkästchen 10 weist auch acht Funktasten 30, 32, 34, 36, 38, 40, 42 und 44 auf. Jede Funktaste weist ein zugeordnetes Bild 46, 48, 50, 52, 54, 56, 58 bzw. 60 auf. Jedes dieser Bilder zeigt ein verfügbares Merkmal. Beispielsweise zeigen die Bilder 46, 48, 50 und 52 die Existenz von Symbolen, und die Bilder 54, 56, 58 und 60 zeigen Leermuster, die bei den Venn-Diagrammen verwendet werden können. Der Benutzer kann verschiedene Funktasten anklicken, um jegliche der Symbole oder Leermuster auszuwählen oder das Auswählen von ihnen aufzuheben. Wenn der Benutzer die Speichertaste 12 anklickt, werden die ausgewählten Muster und Symbole gespeichert. Alternativ können die Bilder 46, 48, 50, 52, 54, 56, 58 und 60 getrennte Bildzeichen sein.
Dialogkästchen sind gewöhnlich einfacher zu erzeugen und zu verwalten als Dokumentfenster. Viele Computer haben einen Dialogverwalter, der die Verwendung von Dialogkästchen verwaltet oder überwacht. Der Dialogverwalter liest eine Beschreibung des Dialogkästchens und der Positionen innerhalb des Dialogkästchens. Der Dialogverwalter zeichnet dann das Dialogkästchen und verarbeitet Benutzeraktionen, die das Dialogkästchen beeinflussen (oder verwaltet die Reaktion auf diese). Die Aufgaben des Dialogverwalters umfassen das Manipulieren von Positionen in einem Dialogkästchen unter anderem einschließlich des Zeichnens einer Position, des Löschens einer Position, des Änderns des Aussehens einer Position und des Überwachens des Behandelns eines die Position beeinflussenden Ereignisses.
Gegenwärtig sind das Verhalten eines Dialogkästchens und seiner Positionen im Dialogverwalter, im Fenstersystem oder in einer Anwendung definiert. Der Ausdruck "Definieren des Verhaltens" umfaßt unter anderem das Definieren, wie und wo Dialogkästchen und Dialogpositionen zu zeichnen sind, das Definieren verschiedener Attribute der Positionen (beispielsweise Font, Punktgröße, Farbe, Test usw.) und das Definieren der Aktionen, die ausgeführt werden müssen, wenn ein Ereignis auftritt (beispielsweise wenn ein Benutzer eine Position anklickt, Text in eine Position eingibt, Text in einer Position editiert oder eine andere eine Position oder ein Dialogkästchen betreffende Aktion ausführt). Wenn ein Dialogverwalter und die damit verbundene Software entwickelt werden, enthält der Dialogverwalter in Dialogkästchen zu verwendende vordefinierte Positionen für einen Anwendungsprogrammierer. Demgemäß kann eine Fensterumgebung mit einer Bibliothek vordefinierter Positionen einhergehen.
Die aktuelle Verwendung und die aktuelle Struktur von Dialogkästchen und Dialogpositionen haben hinsichtlich der Softwareentwicklung zu einigen Schwierigkeiten geführt. Eine erste Schwierigkeit tritt auf, wenn der Lieferant des Dialogverwalters oder des Fenstersystems und möglicherweise des Betriebssystems an der Bibliothek vordefinierter Positionen Änderungen vornehmen möchte. Änderungen an der Bibliothek umfassen das Hinzufügen weiterer Positionen oder das Ändern der Definition bereits existierender Positionen. Es ist für das Ändern der Bibliothek gewöhnlich erforderlich, am Dialogverwalter und möglicherweise am Fenstersystem oder am Betriebssystem Änderungen vorzunehmen (der Dialogverwalter kann Teil des Betriebssystems sein, muß dies jedoch nicht). Weiterhin ist es nach Abschließen der Änderungen an der Bibliothek möglicherweise erforderlich, daß das Betriebssystem und der Dialogverwalter neu kompiliert werden, um neue Merkmale auszunutzen. In den meisten Fällen müssen Anwendungen, die auf dem Betriebssystem oder dem Fenstersystem laufen, neu kompiliert werden, um die neuen Merkmale auszunutzen, falls das Betriebssystem, das Fenstersystem oder der Dialogverwalter neu kompiliert wird. Wenn der Lieferant eines Fenstersystems oder eines Dialogverwalters demgemäß zur Bibliothek neue Positionen hinzufügt oder darin Positionen ändert, muß möglicherweise jede auf dem System laufende Anwendung neu kompiliert werden. Dies ist für die Benutzer und Anwendungsentwickler beschwerlich.
Weiterhin können Änderungen an der Bibliothek andere Bibliothekspositionen oder Softwareanwendungen veraltet machen. Falls insbesondere die Definition einer Position geändert wird, funktionieren andere diese Position aufweisende Positionen oder Anwendungen nicht mehr richtig und müssen möglicherweise editiert werden.
Eine dritte Schwierigkeit ergibt sich, wenn ein Anwendungsentwickler (Entwickler) eine Position verwenden muß, die in der vorgegebenen Positionsbibliothek nicht auftritt. Demgemäß erzeugt der Anwendungsentwickler eine neue, speziell eingerichtete Position. Gegenwärtig ist zum Erzeugen einer speziell eingerichteten Position eine große Anstrengung erforderlich. Der Anwendungsprogrammierer muß verstehen, wie der Dialogverwalter arbeitet und wie verschiedene Merkmale des Dialogverwalters überschrieben werden, um einem neuen Positionstyp Rechnung zu tragen. Zu der Schwierigkeit trägt auch die Möglichkeit bei, daß der Anwendungs entwickler keine Möglichkeit hat, auf einfache Weise alle früheren Definitionen und allen früheren Code, die zum Definieren der ursprünglichen Bibliothek verwendet wurden, aufzunehmen.
Ein weiteres Problem besteht darin, daß die Verhaltensdefinition jeder Position Anweisungen für das Verhalten in verschiedenen Situationen aufweisen kann. Wenn der Dialogverwalter auf die Verhaltensdefinition einer Position zugreift, gibt es nur einen Eingabepunkt für den Dialogverwalter. Gegenwärtig werden Verhaltensdefinitionen typischerweise durch eine Anweisungsliste definiert. Wenn der Dialogverwalter auf die Position zugreift, liest er die erste Anweisung aus der Anweisungsliste und dann die zweite Anweisung usw., bis er alle in der Anweisungsliste definierten erforderlichen Schritte abgeschlossen hat. Es ist jedoch möglicherweise nur erforderlich, daß der Dialogverwalter zum Ausführen der gewünschten Aufgabe eine kleine Teilmenge der Anweisungen ausführt. Es ist demgemäß für den Dialogverwalter eine Verschwendung an Verarbeitungszeit, Anweisungen auszuführen, die die gewünschte Aufgabe nicht betreffen. Wenn nur ein Eingabepunkt erforderlich ist, muß ein Entwickler weiterhin Code zum Handhaben des Steuerablaufs von diesem einen Eingabepunkt zu allen Sätzen von Verhaltensdefinitionen erzeugen. Demgemäß muß der Entwickler möglicherweise für einfache Vorgänge des speziellen Einrichtens eine große Menge an Code erzeugen.
Wenn ein Anwendungsentwickler eine speziell eingerichtete Position erzeugt, kann das die neue Position definierende Modul eine vom Anwendungsprogramm getrennte Datei oder Teil von diesem sein. Die Anwendung muß möglicherweise jedesmal kompiliert werden, wenn die Definition der Position geän dert wird. Wenn der Anwendungsentwickler weiterhin eine zweite Anwendung erzeugt, kann die in der ersten Anwendung definierte Position möglicherweise nicht beispielsweise von einem Zeiger in der zweiten Anwendung angesprochen werden, weil sich ein Teil des zum Erzeugen der neuen Dialogposition verwendeten Codes in der ersten Anwendung befindet. Weil der Anwendungsentwickler schließlich verschiedene Codesegmente im Dialogverwalter überschreibt, könnte eine Änderung des Dialogverwalters eine Anwendung (mit einer speziell eingerichteten oder benutzerdefinierten Position) veraltet machen.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß einer ersten Erscheinungsform sieht die Erfindung ein computerimplementiertes Verfahren zum Verwalten von Positionen in einem Dialogkästchen vor, das die folgenden Schritte aufweist: Ausführen einer das Dialogkästchen aufrufenden Anweisung, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: Verwenden eines Dialogverwalters zum Zugreifen auf eine Liste der Positionen, wobei die Liste einen ersten Verweis auf eine objektorientierte Klasse aufweist, Verwenden des Dialogverwalters zum Verfolgen des ersten Verweises auf die objektorientierte Klasse, wobei die objektorientierte Klasse eine Definition einer ersten Position darstellt, und Verwalten der ersten Position unter Verwendung des Dialogverwalters auf der Grundlage eines Exemplars der objektorientierten Klasse.
Gemäß einer zweiten Erscheinungsform sieht die Erfindung auch eine Vorrichtung vor, die ein Dialogkästchen verwendet und folgendes aufweist: einen Prozessor, einen in Verbindung mit dem Prozessor stehenden Speicher, eine in Verbin dung mit dem Prozessor stehende Speichereinrichtung, wobei in der Speichereinrichtung Programmcode zur Programmierung des Prozessors zum Durchführen des Schritts des Ausführens einer das Dialogkästchen aufrufenden Anweisung gespeichert ist, wobei die Vorrichtung dadurch gekennzeichnet ist, daß in der Speichereinrichtung Programmcode zum Programmieren des Prozessors zum Durchführen der folgenden Schritte gespeichert ist: Verwenden eines Dialogverwalters zum Zugreifen auf eine Liste der Positionen, wobei die Liste einen ersten Verweis auf eine objektorientierte Klasse beinhaltet, Verwenden des Dialogverwalters zum Verfolgen des ersten Verweises auf die objektorientierte Klasse, wobei die objektorientierte Klasse eine Definition einer ersten Position darstellt, und Verwalten der ersten Position unter Verwendung des Dialogverwalters auf der Grundlage eines Exemplars der objektorientierten Klasse, ein in Verbindung mit dem Prozessor stehendes Anzeigegerät und eine in Verbindung mit dem Prozessor stehende Eingabeeinrichtung.
Die vorliegende Erfindung ist darauf gerichtet, die Nachteile des Stands der Technik zu überwinden. Die vorliegende Erfindung ist demgemäß in einer Ausgestaltung auf ein Dialogpositions-Schnittstellen-Definitionsobjekt gerichtet, das das einfache und wirksamere Erzeugen speziell eingerichteter Dialogpositionen ermöglicht. Die Vorteile des Dialogpositions-Schnittstellen-Definitionsobjekts (nachfolgend als "IDO" bezeichnet) umfassen die Eigenschaft der Langlebigkeit. Das heißt, daß eine Änderung in der Dialogpositionsbibliothek ein IDO gewöhnlich nicht veraltet macht. Weiterhin ist ein IDO unabhängig. Das heißt, daß ein IDO nicht Teil des Betriebssystems, des Fenstersystems, des Dialogverwalters oder der Anwendung ist. Demgemäß kann das IDO editiert werden, ohne daß es unbedingt erforderlich ist, die Anwendung, das Fenstersystem, den Dialogverwalter oder das Betriebssystem neu zu kompilieren. In ähnlicher Weise würde eine Änderung in der Positionsbibliothek oder im Dialogverwalter oder in der Anwendung oder im Fenstersystem nicht unbedingt ein Neukompilieren des IDOs erfordern.
Für das Erzeugen einer speziell eingerichteten Position unter Verwendung eines IDOs sind das Schreiben von erheblich weniger Code und ein erheblich geringeres Verständnis des Dialogverwalters erforderlich. Eine mit einem IDO bezeichnete Position kann mehrere Eingabepunkte aufweisen, wodurch das Verringern der beim Ausführen von nicht zum Verhalten gehörenden Befehlen verschwendeten Zeit implementiert wird. Weiterhin braucht ein Benutzer, der ein IDO erzeugt, nur Code für die Eingabepunkte zu erzeugen, die speziell eingerichtet werden, weil es mehrere Eingabepunkte gibt.
Schließlich können unter Verwendung eines IDOs erzeugte Dialogpositionen editiert werden, ohne daß andere Software beeinflußt wird, und sie können ein System zum selbständigen Editieren aufweisen. Die meisten Editierwerkzeuge sind in ein Fenstersystem eingepackt oder werden als gebrauchsfertige Positionen verkauft. Diese Werkzeuge wissen nicht unbedingt, wie eine speziell eingerichtete Dialogposition zu editieren ist. Die Selbsteditierfähigkeit eines IDOs ermöglicht das Editieren einer speziell eingerichteten Dialogposition.
Ein IDO ist unter Verwendung einer objektorientierten Klassenbibliothek (oder Klassenstruktur oder Klassenhierar chie) implementiert. Jede Klasse kann die Verhaltensweisen und Attribute definieren, die in einer bestimmten Position verwendet werden. Eine Klassenbibliothek kann getrennt vom Betriebssystem, vom Fenstersystem, vom Dialogverwalter und von der Anwendung erzeugt werden. Der Anwendungsentwickler fügt zur Klassenbibliothek hinzu, um eine Dialogposition speziell einzurichten. Wenn eine Anwendung geschrieben wird, braucht sie nur einen Verweis auf ein Dialogfenster aufzuweisen. Es wird dann ein Betriebsmittel erzeugt, das das Dialogfenster definiert. Dieses Betriebsmittel weist Verweise auf die verschiedenen im Fenster benötigten Positionen auf. Die Verweise könnten eine Klasse in der Klassenbibliothek angeben. Weil die objektorientierte Klassenbibliothek verwendet wird, ermöglicht das Definieren oder spezielle Einrichten einer neuen Position das Erben aller Merkmale einer Überklasse und das Überschreiben nur der zum speziellen Einrichten erforderlichen betreffenden Merkmale.
Die hier enthaltenen Lehren betreffen eine Klassenstruktur, die eine Grundklasse und eine Unterklasse einschließt. Die Grundklasse weist ein Verfahren auf, das dafür ausgelegt ist, von der Unterklasse geerbt zu werden. Das Verfahren kann das Verhalten einer Position definieren. Ein der Anwendung zugeordnetes Betriebsmittel ist aufgenommen, das zum Speichern eines Verweises auf eine bestimmte Unterklasse ausgelegt ist. Das System weist einen Verwalter auf. Der Verwalter ist dafür ausgelegt, mit dem Betriebsmittel in Verbindung zu stehen, so daß der Verwalter die Unterklasse, auf die verwiesen wurde, finden kann. Der Verwalter ist dafür ausgelegt, eine Position in einem Dialogkästchen entsprechend dem in der Unterklasse (oder Klasse), auf die verwiesen wurde, definierten Verhalten zu manipulieren. Die Grundklasse kann mehrere Verfahren aufweisen. Es kann mehr als eine Unterklasse geben, und jede Unterklasse kann alle oder einige der in der Grundklasse definierten Verfahren erben. Jede Unterklasse kann ihre eigene Unterklasse aufweisen, die Verfahren erben kann. Eine Unterklasse kann ohne Kompilieren der Grundklasse kompiliert werden (und umgekehrt). Weiterhin kann eine Unterklasse ohne Kompilieren der Anwendung oder des Fenstersystems, des Verwalters oder des Betriebssystems (und umgekehrt) kompiliert werden.
Die hier enthaltenen Lehren betreffen auch ein Dialogschnittstellen-Definitionsobjekt zum Definieren einer Position in einem Dialogkästchen. Das Dialogkästchen wird als Teil einer Anwendung verwendet. Die Anwendung weist ein zum Speichern von Informationen bezüglich des Dialogkästchens und zum Verweisen auf diese Informationen ausgelegtes Betriebsmittel auf. Die Informationen werden von einem Verwalter verwendet, um das Dialogkästchen und die Dialogpositionen zu manipulieren. Ein Objekt ist ein Exemplar einer Klasse in einer Klassenbibliothek. Die Klasse beinhaltet Attribute, geerbte Verfahren, die ein erstes Verhalten der Position definieren können, und neue Verfahren, die ein in einer Überklasse definiertes Verfahren überschreiben und ein zweites Verhalten der Position definieren können. Die neuen Verfahren können von Unterklassen geerbt werden.
Die hier enthaltenen Lehren betreffen in einer anderen Hinsicht ein Verfahren zum Erzeugen einer Position in einem Dialogkästchen. Das Verfahren beinhaltet die Schritte des Ausführens einer das Dialogkästchen aufrufenden Anweisung und des Lesens eines dem Dialogkästchen zugeordneten Betriebsmittels. Der Schritt des Lesens eines Betriebs mittels beinhaltet die Schritte des Lesens einer Liste im Dialogkästchen darzubietender Positionen und des Verfolgens eines sich auf ein Objekt beziehenden Verweises in der Liste von Positionen. Das Verfahren beinhaltet weiterhin das Warten auf ein erstes Ereignis und das Ausführen eines dem ersten Ereignis zugeordneten ersten Verfahrens, ohne daß in Reaktion auf das erste Ereignis andere Verfahren ausgeführt werden. Das Ereignis kann ein Zeichnungsereignis sein, und es wird dementsprechend ein Zeichnungsverfahren ausgeführt.
Weiterhin betreffen die hier enthaltenen Lehren ein Verfahren zum Definieren des Verhaltens einer im Dialog zu verwendenden neuen Position. Das Verfahren beinhaltet die Schritte des Definierens von Attributen und des Erbens eines ersten Verfahrens von einer Überklasse. Das erste Verfahren definiert die in Reaktion auf ein erstes Ereignis auszuführende erste Aufgabe. Ein zweites Verfahren wird einschließlich der Schritte des Definierens einer bei einem zweiten Ereignis auszuführenden zweiten Aufgabe von der Überklasse überschrieben. Es wird eine Anwendung erzeugt, die ein Dialogkästchen aufweist. Die Anwendung beinhaltet einen Verweisweg zum ersten und zum zweiten Verfahren. Das erste und das zweite Verfahren können ohne Kopplung mit der Anwendung kompiliert werden.
Diese und andere Aufgaben und Vorteile der Erfindung werden anhand der folgenden Beschreibung, in der die bevorzugten Ausführungsformen der Erfindung in Zusammenhang mit der Zeichnung detailliert ausgeführt werden, klarer hervortreten.

KURZBESCHREIBUNG DER ZEICHNUNG

Fig. 1 zeigt ein Dialogkästchen.
Fig. 2 ist ein Blockdiagramm eines Computersystems, das zum Implementieren der Merkmale der vorliegenden Erfindung verwendet werden kann.
Fig. 3 zeigt ein Überblick über die Systemsoftware.
Fig. 4 ist eine symbolische Darstellung der Struktur einer Datei.
Fig. 5 ist eine symbolische Darstellung eines Betriebsmittels.
Fig. 6 ist eine symbolische Darstellung der Struktur eines Dialogbetriebsmittels.
Fig. 7 ist eine symbolische Darstellung der Struktur eines Dialogpositionslisten-Betriebsmittels.
Fig. 8 ist eine symbolische Darstellung der Struktur einer IDO-Position im Dialogpositionslisten-Betriebsmittel.
Fig. 9 ist eine symbolische Darstellung einer Klassenbibliothek.
In Fig. 10 ist das Flußdiagramm dargestellt, das das Verfahren des Erzeugens einer neuen Position in einem Dialogkästchen beschreibt.
In Fig. 11 ist ein Dialogkästchen mit einer durch ein IDO definierten Position dargestellt.
Fig. 12 ist ein Flußdiagramm zur Erklärung, wie der Dialogverwalter ein IDO manipuliert.
Fig. 13 ist eine symbolische Darstellung der Art, in der sich eine Anwendung, ein IDO und der Dialogverwalter austauschen.
Fig. 14 ist eine symbolische Darstellung der Art, in der der Dialogverwalter zu einem IDO gehörende Ereignisse verarbeitet.
Fig. 15 ist ein Blockdiagramm, in dem die verschiedenen vom Dialogverwalter ausgeführten Routinen dargestellt sind.
Fig. 16 zeigt den DLOG-Betriebsmitteleditor.
Fig. 17 zeigt das DLOG-Menü.
Fig. 18 zeigt ein Fenster zum Definieren der DLOG-Eigenschaften.
Fig. 19 zeigt den DITL-Editor.
Fig. 20 zeigt den DITL-Positionseditor.
Fig. 21 zeigt das DITL-Menü.
Fig. 22 ist ein Flußdiagramm des Verfahrens zum Editieren eines IDOs.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

I. Überblick über die Hardware

In Fig. 2 ist ein Computersystem dargestellt, das zum Implementieren der Merkmale der vorliegenden Erfindung verwendet werden kann. Das Computersystem weist eine mit einem Systembus 111 gekoppelte Haupt-CPU 110 auf. Das System weist eine Tastatur. 112, eine Maus 113 mit einer Maustaste oder eine andere Zeigevorrichtung und einen nichtflüchtigen Speicher 114 in der Art einer Festplatte, eines Diskettenlaufwerks, eines als integrierte Schaltung ausgeführten nichtflüchtigen Speichersystems oder dergleichen auf. In ähnlicher Weise sind ein Befehlsspeicher 115 und ein Arbeitsspeicher 116 mit dem Bus 111 gekoppelt. Im Befehlsspeicher 115 ist zusammen mit anderer zum Betrieb des Systems erforderlicher Software Fensterverwaltungssoftware gespeichert. Der Arbeitsspeicher 116 wird verwendet, um verschiedene Tabellen aufrechtzuerhalten, die von der Software im Befehlsspeicher 115 benötigt werden, um die Anzeige aufrechtzuerhalten.
Das System weist auch eine Anzeigesteuereinrichtung 117 auf, die einen Videospeicher aufweist. Die Anzeigesteuereinrichtung 117 steuert eine Anzeige 118 in der Art eines Kathodenstrahlröhren-Bildschirms, eines LCD-Flachbildschirms oder dergleichen. Das Anzeigesystem 118 weist einen allgemein mit 119 bezeichneten Bildschirm auf. Auf dem Bildschirm 119 ist ein Arbeitsplatz 120 dargestellt. Der Arbeitsplatz 120 ist bei Systemen von Macintosh-Typ mit einer Rechner-Bildschirmdarstellung versehen, die einen Menübalkenbereich 107 für Pull-down-Menüs und einen Fensterbereich 108 zum Anzeigen von Fenstern und Bildzeichen aufweist. Innerhalb des Fensterbereichs 108 des Rechners 120 können mehrere Identifizierer, wie der ein Festplattenlaufwerk darstellende Identifizierer 121, der ein Diskettenlaufwerk darstellende Identifizierer 122 und andere nicht dargestellte Identifizierer, die Dateien, Anwendungen, Bedienfelder oder andere Objekte einschließende Rahmen darstellen, angezeigt werden. Weiterhin können im Fensterbereich des Rechners 120 mehrere Fenster, wie die Fenster 143, 144 und 145, geöffnet werden. Die Fenster 143, 144 und 145 schließen Identifizierer, wie die Identifizierer 146 und 147 im Fenster 143, einen Identifizierer 148 im Fenster 144 und einen Identifizierer 149 im Fenster 145 ein.
Fenster können andere Fenster überlappen, so daß Identifizierer in einem Fenster durch ein anderes Fenster abgedeckt werden können. Die ganze Oberfläche des Identifizierers ist jedoch während eines Ziehvorgangs "heiß", so daß der Benutzer nur ein einen Identifizierer zeigendes Pixel zu belassen braucht, damit der ganze Identifizierer zugänglich ist.
In der Figur sind die Identifizierer als graphische Elemente oder Bildzeichen dargestellt. Alternative Identifizierer können Textelemente, wie der Name des entsprechenden Objekts, sein. Die hier beschriebenen Verhaltensweisen können sowohl auf Textelemente als auch auf graphische Elemente angewendet werden, wie es bei Macintosh-Computern bei in einer Ansicht nach dem Namensmodus oder einer Ansicht nach dem Bildzeichenmodus geöffneten Fenstern geschehen kann.
Innerhalb des Rechners 120 ist ein Cursor 105 dargestellt. Zum Identifizieren eines bestimmten gewünschten Bildzeichens bewegt der Benutzer den Cursor auf der Anzeige, indem er die Maus 113 entsprechend bewegt. Wenn der Cursor über einem der Bildzeichen positioniert ist, ändert sich das Bildzeichen automatisch so, daß es eine invertierte Darstellung annimmt. Der Benutzer kann das Bildzeichen unter Verwendung der Maustaste anklicken und es zu einem anderen Bildzeichen ziehen, das sich im selben Fenster oder in einem anderen Fenster befindet, und dann die Maustaste loslassen, um eine Auswahl dem ersten und dem zweiten Bildzeichen entsprechender Objekte anzugeben.

II. Überblick über die Software

Systemsoftware wird zum Implementieren der verschiedenen Funktionen des Computers und zum Bereitstellen von Routinen, die für Anwendungsentwickler zum Aufrufen oder Aufnehmen in eine Anwendung verfügbar sind, verwendet. Systemsoftwareroutinen können logisch in gemeinhin als Verwalter bekannte Funktionsgruppen eingeteilt werden, die bestimmte Aufgaben oder Benutzerschnittstellenelemente handhaben. Der Fensterverwalter ermöglicht es beispielsweise einer Anwendung, Fenster zu erzeugen, zu verschieben, zu verstecken, in ihrer Größe zu ändern oder auf andere Weise zu manipulieren. In ähnlicher Weise gehören die Teile der Systemsoftware, die es einem Entwickler erlauben, Menüs zu erzeugen und zu manipulieren, zum Menüverwalter. Eine Anwendung kann Systemsoftwareroutinen aufrufen, um Standard-Benutzerschnittstellenelemente zu erzeugen und ihre Aktionen mit anderen offenen Anwendungen zu koordinieren. In Fig. 3, wo ein Überblick über die Systemsoftware dargestellt ist, ist ein Benutzer 140 dargestellt, der die Maus 113 und die Tastatur 112 benutzt. Der Benutzer 140 tauscht sich über eine Benutzerschnittstelle 142 mit der Anwendung 146 aus. Die Benutzerschnittstelle 142 weist typischerweise ein Anzeigesystem auf, wie es beispielsweise in Fig. 2 dargestellt ist. Die Anwendung tauscht sich mit einer Toolbox 148, dem Betriebssystem 150 und zusätzlicher Systemsoftware 152 aus.
Die Toolbox 148 wird zum Implementieren der Benutzerschnittstelle, der Betriebsmittelverwaltung, der Eingabe und Ausgabe von Ton sowie von Text und Graphik verwendet. Die Toolbox weist einen gemeinsamen Satz von Routinen auf, die Anwendungen aufrufen können, um verschiedene Funktionen zu implementieren. Die Toolbox gewährleistet dem Benutzer Vertrautheit und Stetigkeit und hilft dabei, die Größe und die Entwicklungszeit eines Anwendungscodes zu verringern. Die Toolbox ist logisch in gewöhnlich als Manager bekannte Funktionsgruppen eingeteilt, die bestimmte Aufgaben für Benutzerschnittstellenelemente behandeln. Im folgenden wird eine Beschreibung einiger der verschiedenen Manager gegeben, die eine gegebene Toolbox aufweisen kann. Eine detailliertere Beschreibung der Toolbox und der Systemsoftware kann in "Inside Macintosh, Overview", Apple Computer, Inc., 1992, Addison-Wesley Publishing Company, worauf hiermit verwiesen sei, und in "Inside Macintosh, Macintosh Toolbox Essentials", Apple Computer, Inc., 1992, Addison-Wesley Publishing Company, worauf hiermit verwiesen sei, angetroffen werden.
Der Fensterverwalter ermöglicht es einem Entwickler, Fenster verschiedener Typen zu erzeugen und zu verwalten. Der Dialogverwalter ermöglicht es einem Entwickler, Dialogkästchen zu erzeugen und zu verwalten. Der Steuerverwalter ermöglicht es dem Entwickler, Steuerungen, wie Tasten, Funktasten, Auswahlkästchen, Pop-up-Menüs, Rollbalken und anwendungsdefinierte Steuerungen zu erzeugen und zu verwal ten. Der Menüverwalter ermöglicht es dem Entwickler, die Menübalken einer Anwendung und die darin enthaltenen Menüs zu erzeugen und zu verwalten. Der Menüverwalter handhabt auch das Zeichnen von Menüs und Benutzeraktionen innerhalb eines Menüs. Der TextEdit-Verwalter stellt einfache Textformatier- und Texteditierfähigkeiten, wie Texteingabe, Textauswahl, Ausschneiden und Pasten bereit. Anwendungen, die nicht in erster Linie die Textverarbeitung betreffen, können zum Ausführen der meisten Textmanipulationen den TextEdit-Verwalter verwenden. Der Betriebsmittelverwalter ermöglicht es einer Anwendung, Betriebsmittel zu lesen und zu schreiben. Der Suchprogramm-Schnittstellenverwalter ermöglicht es einer Anwendung, mit dem Suchprogramm, der Anwendung, die dabei hilft, Dateien zu verfolgen, und die die Rechneranzeige des Benutzers verwaltet, Informationen auszutauschen. Der Zwischenspeicherverwalter ermöglicht es einer Anwendung, Informationen zwischen Anwendungen auszuschneiden und zu pasten. Der Hilfeverwalter ermöglicht es einer Anwendung, Blasen-Online-Unterstützung bereitzustellen. Der Listenverwalter ermöglicht es einer Anwendung, sichtbare Listen von Positionen zu erzeugen. Der Tonverwalter stellt Tonausgabefähigkeiten bereit. Der Toneingabeverwalter stellt für mit einer Toneingabevorrichtung, wie einem Mikrofon, ausgerüstete Computer Toneingabefähigkeiten bereit. Jeder der verschiedenen Verwalter kann andere Verwalter zum Ausführen von Aufgaben aufrufen. Beispielsweise kann der Dialogverwalter den Fensterverwalter aufrufen, um ein Fenster für ein Dialogkästchen einzurichten.
Das Betriebssystem stellt Routinen bereit, die das Ausführen grundlegender niederer Aufgaben, wie Ein- und Ausgabe von Dateien, Speicherverwaltung und Prozeßsteuerung, ermöglicht. Die Toolbox 148 kann das Betriebssystem 150 zum Ausführen niederer Operationen aufrufen. Eine Anwendung kann auch in der Lage sein, das Betriebssystem 150 direkt aufzurufen.
Die Toolbox ermöglicht das Erzeugen und Verwalten von Teilen einer Benutzerschnittstelle einer Anwendung und vermittelt in gewissem Sinne zwischen der Anwendung und dem Benutzer. Dagegen vermittelt das Betriebssystem im wesentlichen zwischen der Anwendung und der Hardware. Die Anwendung liest und schreibt Dateien beispielsweise nicht durch direktes Lesen von Daten aus dem Medium, auf dem sie gespeichert sind. Die Anwendung ruft vielmehr geeignete Routinen des Dateiverwalters auf. Der Dateiverwalter lokalisiert die gewünschten Daten innerhalb der logischen hierarchischen Struktur von Dateien und Verzeichnissen, die er verwaltet: daraufhin ruft der Dateiverwalter den Vorrichtungsverwalter auf, um die Daten auf der eigentlichen physikalischen Vorrichtung umzuschreiben. Der Dateiverwalter und der Vorrichtungsverwalter isolieren dadurch eine Anwendung von den niederen Einzelheiten des Austauschens mit der verfügbaren Datenspeicherhardware. Demgemäß kann die Toolbox 148 als eine Ebene oberhalb des Betriebssystems 150 angesehen werden. Bei einer alternativen Ausführungsform kann sich die Toolbox auf der gleichen Ebene befinden.
Weiter unten wird eine Beschreibung der verschiedenen Hauptbestandteile eines bevorzugten Betriebssystems gegeben. Der Prozeßverwalter handhabt das Einleiten, Planen und Abschließen von Änwendungen. Er liefert auch Informationen über offene Prozesse. Der Speicherverwalter verwaltet das dynamische Zuordnen und Freigeben von Speicher bei der Speicherplatzaufteilung einer Abwendung. Der Virtuelle Speicherverwalter stellt virtuelle Speicherdienste bereit.
Dies ist insbesondere die Fähigkeit, einen logischen Adressenraum bereitzustellen, der größer ist als die Gesamtmenge des verfügbaren RAMs. Der Dateiverwalter bietet einen Zugriff auf das Dateisystem und ermöglicht es Anwendungen, Dateien zu erzeugen, zu öffnen, zu lesen, zu schreiben und zu schließen. Der Alias-Verwalter hilft dabei, spezifizierte Dateien, Verzeichnisse oder Datenträger zu lokalisieren. Der Platteninitialisierungsverwalter verwaltet den Prozeß des Initialisierens von Platten. Der Vorrichtungsverwalter ermöglicht die Eingabe von an den Computer angeschlossenen Hardwarevorrichtungen und die Ausgabe an diese. Der SCSI-Verwalter steuert den Austausch von Informationen zwischen dem Computer und einer an eine Standard-Kleinrechnerschnittstelle (SCSI) angeschlossenen Peripherievorrichtung. Der Zeitverwalter ermöglicht das periodische oder nach einer spezifizierten Zeitverzögerung erfolgende Ausführen einer Routine. Der Vertikalrücklaufverwalter ermöglicht das Synchronisieren der Ausgabe einer Routine mit dem Neuzeichnen des Bildschirms. Der Herunterfahrverwalter ermöglicht das Ausführen einer Routine, während der Computer herunterfährt oder neu startet.
Die Systemsoftware weist eine Anzahl anderer Teile auf, die zusammen als zusätzliche Systemsoftware 152 bezeichnet werden, welche historisch nicht zur Toolbox 148 oder zum Betriebssystem 150 gehören. Die zusätzliche Systemsoftware 152 stellt einen sehr mächtigen Satz von Diensten bereit, die zum Handhaben von Text und zum Unterstützen der sich ändernden Texthandhabungsanforderungen verschiedener Sprachen und Schreibsysteme verwendet werden können. Die zusätzliche Systemsoftware 152 weist auch eine Zwischenanwendungs-Kommunikationsarchitektur (IAC) und eine Kommunikations-Toolbox auf.
Die IAC liefert einen standardmäßigen und erweiterbaren Mechanismus zur Kommunikation zwischen Anwendungen. Die IAC-Architektur weist die folgenden Hauptteile auf. Der Editierverwalter ermöglicht es Anwendungen, Operationen zwischen Anwendungen zu automatisieren, zu kopieren und zu pasten, so daß die Daten dynamisch geteilt verwendet werden können. Der Ereignisverwalter ermöglicht es Anwendungen, zu Ereignissen zu senden und auf diese zu reagieren. Die Programm-zu-Programm-Kommunikation-Toolbox (PPC) ermöglicht es Anwendungen, Datenblöcke durch Lesen und Schreiben niederer Nachrichtenblöcke miteinander auszutauschen. Sie stellt auch eine Standard-Benutzerschnittstelle bereit, die es einem an einer Anwendung arbeitenden Benutzer ermöglicht, eine andere Anwendung auszuwählen, mit der Daten auszutauschen sind.
Die Systemsoftwareroutinen können in einer Bibliothek gespeichert werden und mit einer Anwendung verknüpft werden. Bei der bevorzugten Ausführungsform liegen diese Routinen in einem Nurlesespeicher (ROM) vor, der durch spezielle Chips im Computer bereitgestellt ist. Wenn eine Anwendung eine Routine aufruft, fängt das Betriebssystem den Aufruf ab und führt den im ROM enthaltenen geeigneten Code aus. Dieser Mechanismus stellt dem Betriebssystem 150 einen Weg bereit, den in Reaktion auf eine bestimmte Systemsoftwareroutine ausgeführten Code zu ersetzen. Statt den ROM-basierten Code für irgendeine Routine auszuführen, kann das Betriebssystem auf Anweisung des Anwendungsentwicklers wählen, irgendeinen Ersatzcode in den RAM des Computers zu laden. Wenn die Anwendung dann die betreffende Routine aufruft, fängt das Betriebssystem den Aufruf ab und führt den RAM-basierten Code aus. ROM-basierten Code erset zender RAM-basierter Code wird als Korrekturcode bezeichnet. Korrekturcode ist gewöhnlich in der sich im Systemordner befindenden Systemdatei gespeichert. Die Systemdatei enthält auch als Betriebsmittel bekannte Datensammlungen, die Anwendungen verwenden können, um das Darstellen der Standard-Benutzerschnittstelle zu unterstützen. Ein weiteres Verfahren zum Hinzufügen von Fähigkeiten zur Systemsoftware besteht darin, ausführbaren Code neuer Routinen als Systemerweiterung aufzunehmen. Erweiterungen sind an einer bestimmten Stelle, dem Erweiterungsordner im Systemordner gespeichert und werden zur Zeit des Hochfahrens des Systems in den Speicher geladen.
Wenn eine Anwendung eine Systemsoftwareroutine aufruft, spielt es gewöhnlich keine Rolle, ob der ausgeführte Code im ROM vorhanden ist, ein aus der Systemdatei in den RAM geladener Korrekturcode ist oder ein Teil einer RAM-basierten Erweiterung ist. Es ist jedoch wichtig, daß an mindestens einer dieser Stellen geeigneter Code existiert, weil die Anwendung abstürzt, falls sie versucht, eine nicht definierte Routine aufzurufen.
Die Systemsoftware teilt die Aktionen des Benutzers in Teilereignisse auf, die nacheinander einzeln zur Handhabung an eine Anwendung übergeben werden. Wenn ein Benutzer 140 beispielsweise eine Taste auf der Tastatur 112 anschlägt, sendet das System die Anwendungsinformation über dieses Ereignis. Alternativ könnte ein Ereignis darin bestehen, daß der Benutzer 140 die Maus 113 anklickt oder eine Diskette 160 in ein Diskettenlaufwerk 162 eingibt. Die an die Anwendung übergebene Ereignisinformation umfaßt die Information, welche Taste gedrückt wurde, wann die Taste gedrückt wurde und ob zum Zeitpunkt des Drückens der Taste Modifizierertaste (beispielsweise die Befehlstaste) heruntergedrückt wurde und dergleichen. Anwendungen reagieren durch Ausführen der jeweils geeigneten Aktionen auf das Ereignis. Anwendungen können zahlreiche Typen von Ereignissen entgegennehmen. Ereignisse werden gewöhnlich in drei Kategorien eingeteilt, nämlich niedere Ereignisse, Betriebssystemereignisse und höhere Ereignisse. Bei Geschehnissen, wie dem Drücken der Maustaste, dem Loslassen der Maustaste, dem Drücken einer Taste auf der Tastatur oder dem Einführen einer Diskette durch den Benutzer gibt der Ereignisverwalter niedere Ereignisse an eine Anwendung zurück. Der Ereignisverwalter gibt auch niedere Ereignisse an eine Anwendung zurück, falls die Anwendung ein Fenster aktivieren muß (also auf der Grundlage davon, ob ein Fenster vor oder hinter einem anderen Fenster liegt, Änderungen an dem Fenster vornehmen muß) oder ein Fenster aktualisieren muß (also die Inhalte der Fenster neu zeichnen muß). Wenn die Anwendung ein Ereignis anfordert und keine anderen Ereignisse mitzuteilen sind, gibt der Ereignisverwalter ein Nullereignis zurück. Der Ereignisverwalter gibt Betriebssystemereignisse an eine Anwendung zurück, wenn das Ändern des Verarbeitungsstatus der Anwendung kurz bevorsteht oder sich der Verarbeitungsstatus geändert hat. Falls ein Benutzer beispielsweise eine Anwendung in den Vordergrund bringt, sendet der Prozeßverwalter ein Ereignis über den Ereignisverwalter zu einer Anwendung. Ein Teil der Arbeit zum Reaktivieren einer Anwendung wird durch den Prozeßverwalter und den Fensterverwalter automatisch ausgeführt. Anwendungen müssen jeglichen weiteren Verarbeitungsanforderungen Rechnung tragen, wenn eine Anwendung reaktiviert wird. Der Ereignisverwalter gibt höhere Ereignisse an eine Anwendung zurück, wenn Kommunikation von einer anderen Anwendung oder einem anderen Prozeß an die Anwendung gerichtet wird.
Fig. 4 ist eine symbolische Darstellung der Struktur einer Datei gemäß der bevorzugten Ausführungsform. Eine Datei 160 weist einen Datenzweig 162 und einen Betriebsmittelzweig 164 auf. Die Datei 160 wird als eine benannte, geordnete Folge von auf einem Datenträger gespeicherten und in zwei Zweige eingeteilten Bytes behandelt. Der Datenzweig 162 enthält Daten, die gewöhnlich von den Benutzern erzeugten Daten entsprechen. Die die Datei erzeugende Anwendung kann die Daten in dem Datenzweig in der jeweils geeigneten Weise speichern und interpretieren. Der Betriebsmittelzweig 164 besteht aus einem Betriebsmittelplan und den Betriebsmitteln selbst. Ein Betriebsmittel ist durch jegliche gemäß einer definierten Struktur gespeicherte Daten gegeben. Die Daten in dem Betriebsmittel werden entsprechend dem Betriebsmitteltyp interpretiert. Betriebsmittel können unter Verwendung eines Betriebsmittelcompilers oder unter Verwendung eines Betriebsmitteleditors durch Kompilieren von Code erzeugt werden. Wenn Daten in eine Datei geschrieben werden, werden sie entweder in den Betriebsmittelzweig der Datei oder den Datenzweig der Datei geschrieben. Daten werden typischerweise unter Verwendung der Dateiverwalterroutinen aus dem Datenzweig gelesen und unter Verwendung des Betriebsmittelverwalters aus einem Betriebsmittelzweig ausgelesen und in diesen geschrieben.
In Betriebsmitteln sind typischerweise Betriebsmitteldaten mit einer definierten Struktur, wie Bildzeichen, Töne und Beschreibungen von Menüs, Steuerungen, Dialogkästchen und Fenstern, gespeichert. Wenn ein Betriebsmittel erzeugt wird, werden ihm ein Betriebsmitteltyp und eine Betriebsmittelkennung zugewiesen. Ein Betriebsmitteltyp ist eine Folge von Zeichen, die einen speziellen Betriebsmitteltyp eindeutig identifiziert, und eine Betriebsmittelkennung identifiziert ein spezielles Betriebsmittel durch eine Zahl. Beispiele von Betriebsmitteltypen sind CODE, WIND, DLOG, DITL und ICON. Ein ICON-Betriebsmitteltyp wird zum Definieren eines Bildzeichens verwendet. Ein WIND-Betriebsmittel wird zum Definieren eines Fensters verwendet. Ein DLOG-Betriebsmittel wird zum Definieren eines Dialogkästchens verwendet. Ein DITL-Betriebsmittel wird zum Definieren einer Dialogpositionsliste (die aus einer großen Anzahl von Positionen in einem gegebenen Dialogkästchen besteht) verwendet. Für eine gegebene Anwendung spezifische Betriebsmittel, wie Beschreibungen von Fenstern, Menüs, Steuerungen und Dialogkästchen, sind im Betriebsmittelzweig der gegebenen Anwendung gespeichert. Ein Betriebsmittelzweig weist eine Betriebsmittelkarte auf, die Einträge enthält, welche den Ort jedes Betriebsmittels im Betriebsmittelzweig liefern. Wenn der Betriebsmittelverwalter den Betriebsmittelzweig einer Datei öffnet, liest er die Betriebsmittelkarte in den Speicher. Wenn der Betriebsmittelverwalter Betriebsmittel in den Speicher liest, ersetzt er ihre Posten in der Betriebsmittelkarte, die die Daten im Speicher handhabt.
Wenn ein Benutzer eine Anwendung öffnet, öffnet die Systemsoftware den Betriebsmittelzweig der Anwendung. Wenn die Anwendung eine Datei öffnet, öffnet die Anwendung typischerweise sowohl den Datenzweig als auch den Betriebsmittelzweig der Datei. Wenn die Anwendung ein Betriebsmittel vom Betriebsmittelverwalter anfordert, folgt der Betriebsmittelverwalter einer speziellen Suchreihenfolge. Der Betriebsmittelverwalter sucht normalerweise zuerst im Betriebsmittelzweig der letzten Datei, die die Anwendung geöffnet hat, nach dem Betriebsmittel. Falls der Betriebsmittelverwalter das Betriebsmittel dort nicht findet, durchsucht er weiterhin jeden für die Anwendung offenen Betriebsmittelzweig in der entgegengesetzten Reihenfolge, in der die Dateien geöffnet wurden. Nach dem Nachsehen in den Betriebsmittelzweigen der Dateien, die die Anwendung geöffnet hat, sucht der Betriebsmittelverwalter den Betriebsmittelzweig der Anwendung. Falls er nicht gefunden wird, sucht der Betriebsmittelverwalter den Betriebsmittelzweig der Systemdatei.

III. Dialogkästchen

Ein Dialogkästchen wurde zuvor im Hintergrund der Erfindung beschrieben. Dieser Abschnitt liefert weitere Einzelheiten über die bevorzugte Ausführungsform eines Dialogkästchens. Wenn ein Dialogkästchen erzeugt wird, muß der Anwendungsentwickler ein Dialogbetriebsmittel (DLOG) und ein Dialogpositionslisten-Betriebsmittel (DITL) definieren. Der Dialogverwalter bekommt den größten Teil der beschreibenden Informationen über Dialogkästchen von diesen Betriebsmitteln. In Fig. 5 sind die Betriebsmittel für eine Dialogkästchen enthaltende Anwendung dargestellt. Der Betriebsmittelzweig 164 weist ein erstes Betriebsmittel zum Speichern von Code 182 auf. Die Anwendung ruft zwei Dialogkästchen auf. Daher weist das Betriebsmittel 164 zwei Dialogbetriebsmittel auf, nämlich DLOG&sub1; 184 und DLOG&sub2; 186. Es gibt für jedes Dialogbetriebsmittel eine entsprechende Dialogpositionsliste. Demgemäß entspricht DLOG&sub2; 184 DiTL&sub1; 188 und DLOG&sub2; 186 DITL&sub2; 190.
In Fig. 6 ist die Struktur eines DLOG-Betriebsmittels 200 dargestellt. Ein Rechteckfeld 202 bestimmt die Abmessungen des Dialogkästchens. Die Fensterdefinitionskennung 204 (Procld) wird verwendet, um zu bestimmen, welcher Typ von Dialogkästchen definiert wird. Beispielsweise können Typen von Dialogkästchen Dialogkästchen, die über den Bildschirm bewegt werden können (also mit einer Maus gezogen werden können), Dialogkästchen, die durch eine Aktion eines Benutzers verworfen werden müssen, bevor irgendwelche andere Aktionen stattfinden können (modales Dialogkästchen) und Dialogkästchen, die nun verwendet werden können oder in den Hintergrund gestellt und später verwendet werden können, sein. Falls das Sichtbarkeitsfeld 206 auf einen Wert 1 gelegt ist, zeigt der Dialogverwalter dieses Dialogkästchen, sobald es in der Anwendung aufgerufen wird. Alternativ kann das Dialogkästchen dann, wenn es aufgerufen wird, definiert und im Speicher eingerichtet werden, und es wäre dann erforderlich, daß ein Zeichne-Dialogkästchen-Befehl angezeigt wird. Eine Schließkästchen-Spezifikation 208 spezifiziert, ob ein Schließkästchen gezeichnet werden soll. Ein Schließkästchen ist ein im Dialogkästchen gezeichnetes Kästchen, das, wenn es angeklickt wird, bewirkt, daß das Dialogkästchen geschlossen wird. Ein Feld 212 ist eine Verweiskonstante (refeon), die jegliche Daten enthält, die eine Anwendung hier speichert. Beispielsweise kann eine Anwendung eine Zahl speichern, die eine Datenposition oder einen Zeiger auf Daten darstellt. Eine Positionslistenkennung 216 ist die Identifikation des die Positionen im Dialogkästchen spezifizierenden Positionslisten-Betriebsmittels (DITL). Ein Fenstertitel 218 ist eine in der Titelleiste von Dialogkästchen dargestellte Pascal-Zeichenkette. Das Ausrichtungsbyte 220 ist ein zusätzliches Byte, das, falls erforderlich, hinzugefügt wird, um zu veranlassen, daß die vorhergehende Pascal- Zeichenkette an einer Wortgrenze endet. Eine Dialog kästchenposition 222 spezifiziert die Position des Dialogkästchens auf dem Bildschirm.
Ein Dialogpositionslisten-(DITL)-Betriebsmittel wird verwendet, um zu spezifizieren, welche Positionen in dem Dialogkästchen vorhanden sind. Das Format und die Struktur eines DITLs 230 sind in Fig. 7 dargestellt. In einem Feld 232 (Positionszählwert minus 1) ist der Wert gespeichert, der um eins kleiner ist als die Gesamtzahl der in diesem Betriebsmittel definierten Positionen. Unterhalb dieses Zählwerts liegt eine variable Anzahl von Positionen (234...236...).
In Fig. 8 ist das Format eines einzelnen IDO-Position in einer DITL dargestellt. Ein Anzeigerechteck 242 wird verwendet, um die Größe und den Ort der Position im Dialogkästchen festzulegen. Das Anzeigerechteck ist in Ecken spezifiziert, die bezüglich des Dialogkästchens lokal sind. Diese Ecken spezifizieren die obere linke Ecke und die untere rechte Ecke der Position. Ein Positionstyp 244 enthält einen den Typ der definierten Position angebenden Wert. In dieses Feld kann beispielsweise eine erste Konstante geladen werden, falls der Positionstyp eine Taste ist, es kann darin eine zweite Konstante geladen werden, falls der Positionstyp ein Anwählkästchen ist, es kann darin eine dritte Konstante geladen werden, falls der Positionstyp ein IDO ist, usw. Ein Handle-Zeiger 246 ist ein Zeiger, der auf eine Klasse verweist (Klassen werden weiter unten erörtert). In einem Klassennamen 248 ist der Name der Klasse gespeichert (wodurch auf die Klasse verwiesen wird), die das IDO definiert.

IV. Objektorientierte Programmierung

Das IDO gemäß der vorliegenden Erfindung ist ein Produkt der objektorientierten Programmierung. Bei der objektorientierten Programmierung sind Aktionen und Daten eng gekoppelt. Das heißt, daß dann, wenn ein Programmierer Daten definiert, auch eine Aktion definiert werden kann. An Stelle eines Satzes von Routinen, die auf irgendeine Weise auf Daten einwirken, gibt es einen Satz von Objekten, die sich untereinander austauschen.
Ein Objekt ist ein Posten, der irgendwelche Daten und einen zugeordneten Satz von auf die Daten einwirkenden Aktionen enthält. Um zu bewirken, daß ein Objekt eine der Aktionen ausführt, wird dem Objekt eine Nachricht gesendet. Es könnte beispielsweise ein Objekt erzeugt werden, das ein Rechteck darstellt. Seine Daten enthalten die Orte der vier Eckpunkte des Rechtecks, und seine Aktionen könnten Zeichnen, Löschen und Bewegen einschließen. Zum Zeichnen eines Rechtecks wird eine Zeichnungsnachricht zum Rechteck gesendet.
Jedes Objekt gehört zu einer Klasse, die die Implementierung einer bestimmten Art eines Objekts definiert. Eine Klasse beschreibt die Daten des Objekts und die Art, in der das Objekt auf eine Nachricht antwortet. Ein Objekt wird als ein Exemplar einer Klasse bezeichnet.
Klassen ähneln sehr Datensatzerklärungen. Ein Programmierer definiert ähnlich wie die Felder eines Datensatzes die privaten Daten für die Klasse. In Klassen werden die Felder als Exemplarvariablen (oder Attribute) bezeichnet. Jedes Exemplar einer Klasse weist ebenso, wie jede Variable eines Datensatztyps die gleichen Felder aufweist, ihre eigenen Exemplarvariablen auf. Wenn eine Nachricht zu einem Objekt gesendet wird, implementiert eine Softwareroutine diese Nachricht. Diese Routine wird als ein Verfahren bezeichnet. Auf diese Weise beinhaltet eine Klassendefinition Exemplarvariablen und -verfahren. Es ist wichtig, zu beachten, daß Nachricht und Verfahren einander nicht gleichen. Eine Nachricht ist das, was zu einem Objekt gesendet wird. Das Verfahren ist die Art, in der ein Objekt auf eine Nachricht antwortet. Demgemäß hat eine gegebene Klasse einen Klassennamen, Exemplarvariablen, Nachrichten, die ihr gesendet werden können, und Verfahren, die sie ausführt, wenn sie eine bestimmte Nachricht empfangen hat.
Eine Klasse kann in bezug auf eine existierende Klasse definiert werden. Die neue Klasse wird als die Unterklasse bezeichnet, und die bestehende Klasse wird als die Überklasse bezeichnet. Eine Klasse ohne eine Überklasse wird als eine Wurzelklasse bezeichnet. Eine Unterklasse erbt alle Exemplarvariablen und -verfahren von ihrer Überklasse. Erben bedeutet, daß eine in einer gegebenen Klasse existierende Variable oder ein darin existierendes Verfahren automatisch in der Unterklasse existierten. Unterklassen können zusätzliche Exemplarvariablen und -verfahren definieren. Unterklassen können auch durch die Überklasse definierte Verfahren überschreiben. Das Überschreiben eines Verfahrens bedeutet das Erzeugen eines neuen Satzes von Befehlen, so daß die Unterklasse auf die gleiche Nachricht wie eine Überklasse antwortet, jedoch zum Antworten auf die Nachricht ihr eigenes Verfahren (ein neues Verfahren) verwendet. Falls ein Verfahren nicht überschrieben wird, antwortet die Unterklasse ebenso wie die Überklasse auf das Verfahren.
In Fig. 9 ist eine hierarchische Klassenbibliothek (oder eine Klassenstruktur oder eine Klassenhierarchie) dargestellt. Eine Klasse 300 stellt die Wurzelklasse dar. Eine Klasse 302 ist eine Unterklasse der Wurzelklasse. Eine Klasse 304 ist auch eine Unterklasse der Wurzelklasse 300. Die Klasse 304 weist auch Unterklassen 306 und 308 auf. Daher ist die Klasse 304 eine Überklasse von 306 und 308, jedoch eine Unterklasse der Klasse 300. Demgemäß kann jedes in der Klasse 300 definierte Verfahren in den Klassen 304, 306 und 308 vererbt werden. Falls die Klasse 304 ein Verfahren in der Klasse 300 überschreibt, erben die Klassen 306 und 308 das neue Verfahren. Beispielsweise definiert die Klasse 300, wie ein Kreis zu zeichnen ist (siehe Kästchen 301), und sie weist zwei Exemplarvariablen, nämlich Mittelpunkt und Radius, auf. Die Klasse 300 weist auch zwei Verfahren auf, nämlich DrawCircle und EraseCircle. Das DrawCircle-Verfahren zeichnet einen Kreis, wenn die Klasse 300 die Nachricht "DrawCircle" empfangen hat. Wenn die Klasse 300 die Nachricht "EraseCircle" empfängt, löscht das Verfahren EraseCircle den gezeichneten Kreis. Die Unterklasse 302 enthält eine weitere Exemplarvariable, nämlich Farbe. Dies bedeutet, daß die Klasse 302 auch Mittelpunkt und Radius von der Klasse 300 erbt. Weiterhin erbt die Klasse 302 DrawCircle von der Klasse 300. Die Klasse 302 überschreibt jedoch EraseCircle, so daß ein neues EraseCircle-Verfahren ausgeführt wird, wenn eine Nachricht "EraseCircle" zu einem Objekt der Klasse 302 gesendet wird. Die Klasse 302 weist auch ein weiteres Verfahren, nämlich FillInCircle auf, das einen zuvor gezeichneten Kreis ausfüllt, um ihn massiv zu machen. Die zum Ausfüllen des Kreises verwendete Tinte wird durch die Variable Farbe bezeichnet. Demgemäß sendet eine Routine, die versucht, einen massiven Kreis zu zeichnen, eine Nachricht, die zuerst den Wert von Farbe angibt, sie sendet eine Nachricht, die den Wert von Radius angibt, sie sendet eine Nachricht, die den Wert von Mittelpunkt angibt, sie sendet eine Nachricht, um den Kreis zu zeichnen (DrawCircle), und sie sendet dann eine Nachricht, um den Kreis auszufüllen (FillInCircle). Wenn die Anwendung abgeschlossen ist, wird eine Nachricht zu EraseCircle gesendet. Das Kästchen 310 stellt ein Objekt dar, das ein Exemplar der Klasse 302 ist. Das Objekt 310 wird in einer Anwendung erzeugt. Innerhalb der Anwendung können Nachrichten zum Objekt 310 gesendet werden.

V. Systemobjektmodell

Das Systemobjektmodell (SOM) von IBM, das auf dem Fachgebiet bekannt ist, ist eine Technologie zum Verpacken objektorientierter Klassenbibliotheken. SOM ermöglicht es, daß Objekte in Klassen gemeinsam verwendet werden und über Sprachen hinweg importiert werden, und es konkurriert nicht mit solchen Sprachen, wie SmallTalk, C++ oder irgendeiner anderen Programmiersprache. Statt dessen ergänzt SOM Sprachen, weil es weniger eine Sprachentechnologie als vielmehr eine Verpackungstechnologie für binären Code ist. Dieses Merkmal ermöglicht es Verkäufern, geeignet kompilierte Objektbibliotheken ohne Quellcode zu verschicken. SOM ermöglicht das Erzeugen von sprachenunabhängigen Objekten. Dies bedeutet, daß mit SOM in einer Sprache eingerichtete Klassenbibliotheken von in einer anderen Sprache geschriebenen Kundenprogrammen verwendet und erweitert werden können. Wegen des Aufbrechens der Sprachbarriere ermöglicht SOM Entwicklern, die Implementierungseinzelheiten einer SOM-Klasse, wie das Hinzufügen neuer Verfahren, das Editie ren oder Löschen von Variablen, das Einfügen einer neuen Stammklasse in die Erbhierarchie und das Entfernen von auswärtigen Verfahren in der Hierarchie einfacher zu ändern, ohne daß es erforderlich wäre, daß Kundenprogramme umkompiliert werden. Hierdurch wird die Fähigkeit verbessert, wirklich aufwärtskompatible Klassenbibliotheken zu verteilen. Wenngleich SOM bei der bevorzugten Ausführungsform verwendet wird, kann SOM durch ein anderes Modell oder durch eine Umgebung, in der die Sprachkompatibilität kein Problem ist, ersetzt werden. Weitere Informationen zu SOM können in "OS/2 2.1 Application Programmer's Guide" von Jody Kelly, Craig Swearingen, Dawn Bezviner und Theodore Shrader, 1994, Van Nostrand Reinhold, worauf hiermit verwiesen sei, angetroffen werden.

VI. Schnittstellendefinitionsobjekte

Ein IDO ist ein zum Definieren einer Position in einem Dialogkästchen verwendetes Objekt. Ein IDO ist ein Exemplar einer Klasse. Die Klassenbibliothek (oder die Klassenhierarchie oder die Klassenstruktur) wird unter Verwendung von SOM eingerichtet. Jede Klasse definiert einen anderen Positionstyp. Beispielsweise kann eine Taste durch eine Klasse definiert werden, kann ein Bildzeichen durch eine zweite Klasse definiert werden, kann ein Kästchen durch eine dritte Klasse definiert werden usw. Ein IDO ist ein Objekt (oder ein Exemplar) einer dieser Klassen.
Weil ein IDO ein Exemplar einer Klasse ist, erbt die Klasse alle Verfahren und Exemplarvariablen der Überklasse. Die verwendete Klassenhierarchie weist eine Grundklasse auf. Die Grundklasse ist eine relative Wurzelklasse. Eine Grundklasse kann einer Wurzelklasse gleichen oder sie kann eine Unterklasse einer Wurzelklasse sein. Die Grundklasse ist die effektive oder relative Wurzelklasse für eine Gattung von Objekten. Für die Zwecke von Dialogkästchen dient demgemäß eine bestimmte Klasse in einer möglicherweise riesigen Systemklassenhierarchie als Grundklasse. Dies ist tatsächlich möglicherweise nicht die Wurzelklasse für die ganze Klassenhierarchie. Für die Zwecke von Dialogkästchen erscheint sie jedoch als die Wurzelklasse. Alternativ kann es eine eigene Klassenhierarchie für Dialogkästchen geben. Daher wäre die Grundklasse auch die Wurzelklasse. Weiter unten wird ein Beispiel eines Typs (der bevorzugten Ausführungsform) einer Grundklasse für ein IDO gegeben.
Im folgenden wird eine Beschreibung der Felder der Grundklasse gegeben.
"DialogRef fDialog" gibt das Dialogkästchen an, das diese Position aufweist. "DialogItemIndex1 fIndex" gibt den Term dieser Position an, der sich innerhalb des Dialogkästchens befindet. Demgemäß kann das IDO unter Verwendung von fDialog und fIndex unter Verwendung von GetDialogItem und GetDialogItemProperty usw. auf jegliche allgemeine Informationen für sich selbst zugreifen und diese definieren. "Rect fRect" gibt das begrenzende Rechteck für die Position an (in für den Dialog, in dem es vorhanden ist, lokalen Korrdinaten). "Short fIdleTimeWaitPeriod" spezifiziert, wie lange der Dialogverwalter zwischen Aufrufen der Bereit schaftsprozedur dieser Position warten sollte (in 1/60 einer Sekunde). Jede Position kann dementsprechend eine Bereitschaftszeit empfangen. Falls die Position keine Bereitschaftszeit benötigt, sollte sie dieses Feld auf kDoesNotNeedIdleTime (-1) setzen. Positionen bekommen standardmäßig keine Bereitschaftszeit.
Im folgenden Text werden die Verfahren der Grundklasse beschrieben. Es sei bemerkt, daß eine Klasse dann, wenn sie sich für ein gegebenes Verfahren nur standardmäßig verhält, das Verfahren der Überklasse nicht zu überschreiben braucht. Der Dialogverwalter wählt bis zum ererbten Verfahren der Position durch, falls kein Verfahren von der Klasse implementiert ist. Gewöhnlich bedeutet das in der Grundklasse definierte Verhalten, daß sehr wenig oder nichts getan wird.
"Initialize (void)" wird aufgerufen, wenn ein Exemplar des IDOs erzeugt wird (zur Erzeugungszeit des Dialogkästchens), um es dem IDO zu ermöglichen, seine Felder geeignet festzulegen. Das IDO ruft die geerbten SetData auf, bevor es einen Teil seiner eigenen Arbeit ausführt, um die Standardinitialisierungsaufgaben auszuführen. Dies schließt das Definieren des geeigneten Werts für fIdleTimeWaitPeriod ein. (Dieser ist standardmäßig auf -1 gelegt. Falls eine Dialogposition Bereitschaftszeit benötigt, sollte sie fNeedsIdleTime auf die Anzahl der zwischen Aufrufen des DoIdle-Verfahrens gewünschten Zeitabschnitte setzen.)
Bevor dieses Verfahren aufgerufen wird, hat der Dialogverwalter alle Eigenschaften einer IDO-Position festgelegt, die seine statischen Anfangsdaten definieren. (Beispielsweise hat ein IDO anzeigender Text eine Eigenschaft des Typs "TEXT", die seinen Anfangstext spezifiziert.) Das IDO kann durch ein GetProperty-Dienstverfahren auf jegliche dieser Eigenschaften zugreifen.
"Dispose (void)" wird zur Beseitigungszeit für die Position aufgerufen (gewöhnlich dann, wenn sein Dialog beseitigt wird), so daß sie für jegliche dynamisch zugewiesene Daten frei sein kann.
"GetStaticData (void)" wird aufgerufen, wenn der Dialogverwalter eine verkapselte Form der Daten der Position benötigt (die er mit dem SetData-Verfahren einlesen kann).
"EditStaticData (void)" wird aufgerufen, um das Editieren einer Position zu ermöglichen. Dies ähnelt dem, was geschieht, wenn jemand auf eine Dialogposition in ResEdit doppelklickt, nämlich daß ein Dialogkästchen auf dem Bildschirm angezeigt wird, das es dem Benutzer erlaubt, spezielle Felder für die Position zu spezifizieren.
"DoActivate (Boolean isActive)" wird aufgerufen, wenn der Dialog der Position ein aktives Ereignis empfängt. IsActive ist wahr, wenn die Position aktiviert werden sollte, und falsch, wenn sie deaktiviert werden sollte.
"DoDraw (void)" wird aufgerufen, wenn eine Position sich selbst neu zeichnet. Das IDO kann annehmen, daß sein Port (sein Dialog) festgelegt worden ist und daß sein Status (einschließlich der Stiftart des Ports, von Textinformationen usw.) unabhängig davon, was das IDO tut, wenn es sich selbst zeichnet, bewahrt bleibt. Das IDO kann auch annehmen, daß das Eraseßackground-Verfahren bereits aufgerufen wurde.
"CursorEnteredRect (void)" wird aufgerufen, wenn der Cursor das Rechteck der Position eingegeben hat: Falls das IDO den Cursor zu diesem Zeitpunkt ändern möchte, implementiert es dieses Verfahren, was ansonsten nicht erforderlich ist.
"DoMouseDown (EventRecord *theEvent)" wird aufgerufen, wenn der Benutzer innerhalb des Rechtecks der Position geklickt hat. Das Verfahren gibt "wahr" zurück, falls es vom Benutzer ausgewählt wurde, wodurch angegeben wird, daß der Dialogverwalter den Index der Position über DialogSelect oder ModalDialog (im Parameter itemHit) zur Anwendung zurücksendet.
"DoKeyDown (EventRecord *theEvent)" wird aufgerufen, um auf ein DoKeyDown-Ereignis (Herunterdrücken einer Taste auf der Tastatur) zu reagieren. Der Rückgabewert ähnelt dem Rückgabewert von DoMouseDown.
"SetKeyboardFocus (Boolean isFocussed)" wird aufgerufen, wenn der Benutzer den Bereich der Position mit dem Tabulator angewählt oder darin geklickt hat (oder außerhalb von diesem, was vom Wert von isFocussed abhängt) und die Tastatur nun auf sie konzentriert ist, und es sollte sich dementsprechend auf andere Weise zeichnen.
"DragEnteredItem (DragReference theDrag)" wird aufgerufen, wenn ein Ziehen durch den Ziehverwalter (Drag Manager) das begrenzende Rechteck der Position des IDOs eingegeben hat. Falls diese Position dieses Ziehen akzeptieren kann, sollte sie ShowDragHilite aufrufen und "wahr" zurückgeben. Sie sollte ansonsten "falsch" zurückgeben.
"DragInItem (DragReference theDrag)" wird aufgerufen, wenn ein Ziehen über die gegebene IDO-Position fortgesetzt wird. Dies wird nur dann aufgerufen, falls diese Position in der DragEnteredItem-Routine "wahr" zurückgegeben hat. Dieses Verfahren zeichnet einen Einfügungspunkt oder nimmt nach Bedarf irgendeine für die Position spezifische Ziehrückkopplung vor.
"DragLeftItem (DragReference theDrag)" wird aufgerufen, falls ein Ziehen das begrenzende Rechteck dieser Position verläßt. Der Dialogverwalter ruft HideDragHilite auf, bevor dieses Verfahren aufgerufen wird, es sollten jedoch jegliche andere das Ziehen verfolgende Säuberungsaufgaben hier ausgeführt werden.
"DropInItem (DragReference theDrag)" wird aufgerufen, wenn der Dialog im begrenzenden Rechteck dieser Position ein Ziehen empfängt. Es ist die Pflicht der Position, die Daten bei dem Ziehen zu übernehmen und die eigenen Daten dementsprechend zu aktualisieren. Das Verfahren gibt jedes OSErr zurück, das für einen DragReceiverHandler gültig ist (für Einzelheiten sei auf die Dokumentation des Ziehverwalters hingewiesen).
Die folgenden Dienstverfahren sind in der Grundklasse für ein IDO implementiert und als Dienstroutinen zur Verwendung durch jede einer Unterklasse angehörende IDO-Position vorgesehen. Diese Verfahren sollten nicht überschrieben werden.
"SetProperty (OSType propertyType, void* propertyData, unsigned long propertySize)" ermöglicht es einer Position, sich selbst Daten jedes Typs und jeder Größe zuzuweisen, so daß auf sie (a) durch die Position, durch die Anwendung oder den Dialogverwalter zugegriffen werden kann und daß sie (b) in einer "flachen" Art beliebig speicherbar sind, so daß jede Position ihre statischen Daten konsistent beliebig speichern kann. Diese Routine ruft SetDialogItem- Property auf, um dies zu erreichen.
"GetProperty (OSType propertyType, void* propertyData, unsigned long propertySize, unsigned long* actual- PropertySize)" ist das Komplement des GetProperty-Verfahrens und erlaubt es der Position, auf jede beliebige Eigenschaft zuzugreifen.
"Handle GetResourceFromMyChain (OSType resType, short resID)" richtet die Betriebsmittelkette so ein, daß der Betriebsmittelzweig des IDOs aufgenommen wird. Dies ermöglicht das Bündeln des Betriebsmittels des IDOs mit zugeordneten Betriebsmitteln.
Wie oben beschrieben wurde, kann jede Klasse viele Verfahren aufweisen. Wenn eine Nachricht vom Dialogverwalter zu einem Objekt gesendet wird, braucht nur ein Verfahren aufgerufen zu werden. Demgemäß gibt der Dialogverwalter das Objekt beim jeweiligen Verfahren ein. Das heißt, daß jedes Verfahren als ein Eingabepunkt angesehen werden kann. Falls nur ein Verfahren ausgeführt werden muß, besteht kein Grund, daß der Computer andere Codezeilen liest oder ausführt, die nicht zu diesem einen Verfahren gehören. Es wird dementsprechend gesagt, daß jedes Objekt mehrere Eingabepunkte aufweist. Jeder Eingabepunkt liegt bei einem Verfahren.
In Anhang A ist eine detailliertere Codeliste für jedes Verfahren in der Grundklasse angegeben. Die meisten Verfahren in der Grundklasse richten Definitionen für die Entwicklung in Unterklassen ein. Der nächste Schritt besteht darin, Unterklassen einzurichten. Weil jede Unterklasse Teil der Klassenhierarchie ist, können sie alle Exemplarvariablen oder Attribute und die Verfahren von der Grundklasse erben. Der Entwickler überschreibt je nach dem, wie es erforderlich ist, um das Verhalten der gewünschten Position zu erreichen, die Verfahren in der Grundklasse. Das Überschreiben eines Verfahrens beinhaltet das Hinzufügen von Befehlen (Quellcode) zum Definieren einer Liste zu unternehmender Schritte, wenn eine dieses Verfahren aufrufende Nachricht empfangen wird.
Beispielsweise könnte eine Unterklasse definieren, wie ein Rechteck als ein Kästchen gezeichnet werden soll. Wenn ein Anwendungsentwickler dann ein Rechteck als eine Position in einem Dialog benötigt, richtet er ein Objekt ein, das auf diese spezielle Unterklasse verweist. Falls ein Anwendungsentwickler ein Kästchen braucht, in dem sich Text befindet, erzeugt er eine neue Unterklasse von der Unterklasse des Kästchens. Die neue Unterklasse, die als GroupingRect bezeichnet sei, erbt alle Verfahren von der Unterklasse des Kästchens. Weiterhin kann die neue Unterklasse einige der Verfahren von der Unterklasse des Kästchens modifizieren, um Text hinzuzufügen.
Es ist bei Verwendung von IDOs recht einfach, eine neue Position zu erzeugen. Ein Entwickler sucht die Klasse, die der Form nach der neuen Position am nächsten kommt. Sobald diese Klasse lokalisiert wurde, richtet der Entwickler lediglich eine neue Unterklasse ein, die alle Verfahren und Exemplarvariablen erbt. Der Entwickler braucht nicht alle Einzelheiten der geerbten Verfahren zu wissen. Der Entwickler braucht den Steuerablauf des Dialogverwalters nicht zu kennen. Der Entwickler braucht lediglich jegliche Verfahren zu überschreiben, die zum Implementieren des speziellen Einrichtens der neuen Position erforderlich sind.
In Fig. 10 ist das Verfahren des Erzeugens eines neuen Typs einer Dialogposition dargestellt. Der erste Schritt (350) besteht darin, eine neue Unterklasse einzurichten. Für das Einrichten einer neuen Unterklasse ist das Verknüpfen oder Verbinden mit der Klassenhierarchie erforderlich. Der Entwickler muß entscheiden, welche existierende Klasse in der Klassenhierarchie die unmittelbare Überklasse für die neue Unterklasse sein soll. Beispielsweise ist beim weiter unten beschriebenen GroupingRect-Beispiel die unmittelbare Überklasse die Grundklasse. Der Entwickler muß entscheiden, welche Variablen oder Verfahren zu überschreiben sind und welche neuen Verfahren oder Variablen hinzuzufügen sind. Der Entwickler definiert dann (im Schritt 352) jegliche neue Exemplarvariablen. Es ist möglich, daß der Entwickler keine neuen Variablen definieren muß. Der Entwickler überschreibt dann (im Schritt 354) jegliche zum speziellen Einrichten der neuen Position erforderlichen Verfahren. Es ist möglich, daß keine Verfahren überschrieben zu werden brauchen. Der Entwickler kann auch an die Unterklasse anhängen (Schritt 356). Das Anhängen an die Unterklasse beinhaltet das Hinzufügen neuer Exemplarvariablen und das Hinzufügen neuer Verfahren. An diesem Punkt kompiliert der Entwickler die Unterklasse (Schritt 358). Falls der Rest der Klassenhierarchie bereits kompiliert ist, ist es nicht erforderlich, die Klassenhierarchie nach dem Kompilieren einer neuen Unterklasse neu zu kompilieren, weil die neue Unterklasse binär mit der Klassenhierarchie kompatibel sein sollte. Falls das Anwendungsprogramm weiterhin bereits kompiliert ist, besteht kein Bedarf, es nach Kompilieren der Unterklasse zu kompilieren. Das Entwickeln der Position kann am Schritt 358 enden oder fortgesetzt werden. Beispielsweise kann der Entwickler nach dem Verwenden oder Testen der Position entscheiden, daß das IDO editiert werden muß (Schritt 360). Das IDO kann durch Editieren von Text oder unter Verwendung eines Betriebsmitteleditors (siehe die unten angegebene Erörterung) editiert werden. Nach Abschluß des Editierens muß die Unterklasse wieder kompiliert werden (Schritt 362). Wenn die Unterklasse neu kompiliert wird (Schritt 362), ist es möglicherweise nicht erforderlich, den Rest des Codes der Klassenhierarchie, der Anwendung oder des Dialogverwalters neu zu kompilieren.
Zum besseren Verständnis eines IDOs wird das folgende Beispiel angegeben. In Fig. 11 ist ein Dialogfenster 320 dargestellt. Das Dialogfenster 320 weist vier Positionen auf, nämlich eine Taste 322, StaticText 324, StaticText 326 und GroupingRect 328. GroupingRect 328 ist ein IDO.
Es sei von dem Szenario ausgegangen, daß ein Entwickler eine Anwendung erzeugt und entscheidet, daß ein Grouping- Rect erforderlich ist. Das GroupingRect ist ein speziell eingerichtetes IDO, weil es nicht existiert. Zuerst erzeugt der Entwickler eine neue Unterklasse, eine GroupingRect- Unterklasse. GroupingRect ist eine Unterklasse der Grundklasse. Daher erbt GroupingRect die Verfahren und Exemplarvariablen der Grundklasse. Weiterhin überschreibt Grouping- Rect jegliche zum Zeichnen des Rechtecks erforderliche Verfahren. Bei diesem Beispiel überschreibt GroupingRect die Funktion DoDraw. Das neue DoDraw beinhaltet Befehle zum Zeichnen eines Rechtecks. Weiterhin kann GroupingRect das Verfahren EditStaticData überschreiben. Weiter unten ist ein Code für die GroupingRect-Klasse angegeben. Dieser Code ist in IDL, der maschinenspezifischen Sprache von SOM, geschrieben.
Nachdem nun eine Klasse eingerichtet wurde, kann der Anwendungsentwickler eine Anwendung erzeugen, die ein Dialogkästchen aufruft. Der folgende Quellcode (in C geschrieben) zeigt ein Anwendungsprogramm, das ein Dialogkästchen aufruft. Wenngleich ein Dialogkästchen aufgerufen wurde, wurde nicht erwähnt, welche Positionen sich im Dialogkästchen befinden. Diese Information wird in ein Betriebsmittel geladen.
Nach dem Erzeugen des Anwendungsprogramms muß der Anwendungsentwickler ein Betriebsmittel einrichten. Der Entwickler richtet, wie oben beschrieben wurde, ein Dialogbetriebsmittel (DLOG) und ein Dialogpositions-Betriebsmittel (DITL) ein. Der DLOG-Quellcode ist weiter unten dargestellt:
Das oben erwähnte Betriebsmittel zeigt, daß die Abmessungen des Dialogkästchens durch die folgenden vier Werte (100, 100, 210, 360 gegeben sind. Die Fensterdefinitionskennung ist dBoxProc, was bedeutet, daß dies ein modales Dialogkästchen ist. Das Dialogkästchen ist sichtbar, und es wird kein Schließkästchen gezeichnet. Die Positionslistenkennung zeigt auf DITL 128.
Weiter unten ist die Quellcodedarstellung des DITLs 128 dargestellt.
In diesem DITL sind vier Positionen aufgelistet. Die erste Position ist der statische Text (StaticText) bei der durch die vier Werte (10, 100, 25, 155) angegebenen Position und dem dort angegebenen Ort. Der in den Dialog zu gebende statische Text ist "IDO Test".
Die zweite Position ist auch StaticText bei der durch die vier Werte (30, 30, 45, 130) definierten Größe und dem dort angegebenen Ort. Der anzuzeigende Text ist "GroupingRect".
Die dritte Position ist eine IDO-Dialogposition. Die Größe und der Ort sind durch die vier Werte (30, 140, 45, 250) definiert. Der Positionstyp ist als eine IDO-Position spezifiziert, und der Name der IDO-Klasse ist GroupingRect.
Die vierte Position ist eine Taste. Ihr Ort und ihre Größe sind durch die Werte (75, 105, 95, 155) definiert. In der Taste ist der Text "Beenden" enthalten.
Der Dialogverwalter verwendet den Namen der IDO-Klasse, um diese zu finden. Nach dem Lokalisieren der IDO-Klasse speichert der Dialogverwalter einen Zeiger auf die IDO- Klasse im Handle-Feld (siehe Fig. 8, Bezugsnummer 246). Es sei weiterhin beachtet, wie das Format eines IDOs in einer DITL etwas von dem Format für eine vordefinierte Position abweicht. Jede vordefinierte Position hat ihr eigenes, dem Dialogverwalter bekanntes Format. Es wird daran gedacht, daß bei einer Ausführungsform alle vordefinierten Positionen beseitigt werden und daß nur IDOs existieren. Bei der bevorzugten Ausführungsform werden vordefinierte Positionen nicht beseitigt, damit eine Kompatibilität mit existierender Software gegeben ist.
Es sei darauf hingewiesen, daß jegliches spezielle Einrichten in der Klassendefinition vorgenommen wird. Das Betriebsmittel hat einen Zeiger auf die Klasse. Der Quellcode der Anwendung enthält keine Bezüge auf die Klasse. Der Quellcode der Anwendung schreibt lediglich vor, daß ein Dialogkästchen zu verwenden ist. Das Betriebsmittel weiß auch nur, daß ein Dialogkästchen mit einem als GroupingRect bezeichneten IDO einzurichten ist. Grouping- Rect kann jederzeit geändert werden, ohne daß ein Kompilieren des Quellcodes der Anwendung oder des Betriebsmittels oder irgendeiner der Unterklassen erforderlich wäre. Demgemäß wird die Klasse, die die Definition der Position ist, getrennt von der Anwendung eingerichtet. Für das Editieren und Kompilieren der Klasse ist kein Revidieren der Anwendung, des Betriebssystems oder des Dialogverwalters erforderlich. Der das GroupingRect einrichtende Entwickler braucht nichts über die Anwendung zu wissen. Weiterhin braucht der Entwickler von GroupingRect nicht sehr viel über den Dialogverwalter oder die Einzelheiten der Implementierung aller Verfahren in der Überklasse zu wissen.

VII. Arbeitsweise des Dialogverwalters

Fig. 12 ist ein Flußdiagramm, in dem dargestellt ist, wie der Dialogverwalter mit einem IDO arbeitet. Zuerst hat die gegebene Anwendung einen Befehl zum Einrichten eines Dialogs. Demgemäß beginnt der Dialogverwalter in einem Schritt 400 mit dem Einrichten des neuen Dialogs. Der erste Schritt besteht darin, das Betriebsmittel der Anwendung zu lesen (402). Beim Lesen des Betriebsmittels liest der Dialogverwalter zuerst das DLOG-Betriebsmittel, das auf ein DITL-Betriebsmittel zeigt. Beim Lesen des DITLs sieht der Dialogverwalter alle verschiedenen Positionen. Der Dialogverwalter erzeugt dann das Dialogkästchen (404). Falls es im DITL eine IDO-Position gibt, weist die IDO-Position einen Verweis auf eine Klasse auf. Der Dialogverwalter liest die geeignete Klasse und speichert den Handle-Zeiger im DITL (406). Nach dem Lesen aller geeigneten Klassen wird der Dialog angezeigt (408). Alternativ kann der Dialogverwalter mit dem Erzeugen des Dialogkästchens warten, bis die Klasse ausgelesen wurde.
Nach dem Anzeigen des Dialogkästchens übergibt der Dialogverwalter die Steuerung wieder an die Anwendung (410). Wenn ein für den Dialogverwalter relevantes Ereignis auftritt, wird die Steuerung zum Überblicken der Verarbeitung des Ereignisses an den Dialogverwalter übergeben (412). Bei einer anderen Ausführungsform kann der Dialogverwalter das Ereignis selbst empfangen oder das Ereignis vom Ereignisverwalter oder anderen Verwaltern in der Toolbox empfangen. Sobald er das Ereignis empfängt, muß der Dialogverwalter oder das andere Werkzeug, das das Ereignis sendet, herausfinden, um welchen Typ von Ereignis es sich handelt und wo das Ereignis aufgetreten ist. Herausfinden, wo das Ereignis aufgetreten ist, bedeutet Herausfinden, welche Position das Ereignis beeinflußt hat. Falls das Ereignis bei einer von einem IDO erzeugten Dialogposition aufgetreten ist, findet der Dialogverwalter heraus, welches IDO beeinflußt wurde. In einem Schritt 414 bewirkt der Dialogverwalter das Ausführen des geeigneten Verfahrens. Es sei bemerkt, daß das einzige ausgeführte Verfahren dasjenige ist, das der Dialogverwalter mitteilt. Fig. 13 zeigt eine symbolische Darstellung, die beim Erklären des Flußdiagramms aus Fig. 12 helfen kann.
In Fig. 13 ist eine Anwendung 420 mit dem Datenzweig 422 und einem Betriebsmittel 424 dargestellt. Das Betriebsmittel 424 weist ein DLOG 426 mit einem auf ein DITL 430 zeigenden Handle-Zeiger 428 auf. Das DITL 430 weist eine Position auf, die ein IDO ist, und es gibt demgemäß einen auf die GroupingRect-Klasse 436 zeigenden Handle-Zeiger 434. Die GroupingRect-Klasse 436 ist Teil einer Klassenhierarchie 437, die eine Grundklasse 438 aufweist. Die Grundklasse 438 hat zwei Unterklassen, nämlich GroupingRect 436 und Kreis (Circle) 440. Kreis 440 hat zwei Unterklassen, nämlich massiver Kreis (Solidcircle) 442 und unterbrochener Kreis (Brokencircle) 444.
Wenn ein Betriebsmittel eingerichtet wird, liest der Dialogverwalter 446 das DLOG 425, das den Dialogverwalter auf das DITL 430 richtet. Weil das DITL 430 eine Position aufweist, die durch ein IDO definiert ist, richtet der Dialogverwalter 446 den Handle-Zeiger 434 so ein, daß er auf die GroupingRect-Klasse 436 verweist. Der Dialogverwalter 446 erzeugt dann ein IDO 448. Das IDO 448 ist mit unterbrochenen Linien dargestellt, weil es ein Ereignis der GroupingRect-Klasse 446 darstellt. Der Dialogverwalter 445 verwendet das im IDO 448 definierte Verhalten zum Manipulieren der Position. Das Manipulieren einer Position kann bei der bevorzugten Ausführungsform das Senden von Nachrichten einschließen, die das Ausführen jeglicher der Verfahren des IDOs aufrufen.
Fig. 14 zeigt eine symbolische Darstellung davon, wie der Dialogverwalter 446 Ereignisse behandelt. Zur Veranschaulichung ist das in dieser Zeichnung auftretende Ereignis das Drücken von einer der Tasten auf der Tastatur 112 durch den Benutzer. Ein doppelseitiger Pfeil 449 gibt an, daß der Dialogverwalter Ereignisse mit Hilfe anderer Werkzeuge in der Toolbox verarbeitet. An einem Punkt ist der Dialogverwalter 446 im Bereitschaftszustand (er wartet auf ein Ereignis), und die Anwendung weist beispielsweise die Steuerung auf. Der Benutzer drückt die Taste auf der Tastatur 112 und löst ein KeyDown-Ereignis aus. Die Steuerung wird an den Dialogverwalter übergeben, der herausfindet, zu welcher Position KeyDown gehört. Bei diesem bestimmten Dialog (ein angenommener Dialog) gab es drei durch IDOs definierte Positionen. Die erste Position 450 weist Exemplarvariablen 452, ein DoDraw-Verfahren 454, ein DoKeyDown- Verfahren 456 und andere Verfahren 458 auf. Eine Dialogposition 460 weist Exemplarvariablen 462, ein DoDraw-Verfahren 464, ein DoKeyDown-Verfahren 466 und andere Verfahren 468 auf. Eine Dialogposition 470 weist Exemplarvariablen 472, ein DoDraw-Verfahren 474, ein DoKeyDown-Verfahren 475 und andere Verfahren 478 auf. Wie dargestellt ist, weist jede der drei Positionen (450, 460, 470) jeweils ein DoKeyDown-Verfahren auf. Irgendwelche oder alle der drei Positionen (IDOs) könnten das DoKeyDown-Verfahren von der Überklasse geerbt haben, oder das DoKeyDown-Verfahren könnte bei ihnen von der Überklasse überschrieben worden sein.
Sobald der Dialogverwalter herausfindet, daß ein DoKeyDown- Ereignis vorliegt und bei welcher Position das Ereignis aufgetreten ist, geht der Dialogverwalter zu dem geeigneten Objekt und sucht nach dem DoKeyDown-Verfahren. Das heißt, daß eine das DoKeyDown-Verfahren angebende Nachricht zum Objekt gesendet wird. Falls in diesem Fall die Taste vom Benutzer heruntergedrückt würde, während er sich am oberen Teil der vom IDO 460 definierten Position befand, teilt der Dialogverwalter das DoKeyDown-Verfahren 456 mit.
Der Dialogverwalter führt alle mit Bezug auf die Fig. 11-13 beschriebenen Aufgaben aus, während verschiedene Routinen verwendet werden. In Fig. 15 sind der Dialogverwalter und eine symbolische Darstellung der zu Dialogpositionen gehörenden Routinen dargestellt. Beispielcode für diese Routinen kann in Anhang B gefunden werden.
CountDITL 502 bestimmt die Anzahl der Positionen in einer Dialogpositionsliste. GetDialogItem 504 gibt alle zu einer Position gehörenden Informationen zurück. SetDialogItem 506 setzt die gegebenen Spezifikationen für die Dialogposition auf den gegebenen Index in der Positionsliste. SetDialog- DefaultItem 50 gibt an, welche Position im gegebenen Dialogkästchen die Standardwahl ist. SetDialogcancelItem 510 gibt an, welche Position in dem Dialogkästchen eine Löschtaste ist. Beispielsweise kann ein Dialogkästchen den Benutzer fragen, ob er alle Änderungen in einer Datei speichern möchte, und die Wahlmöglichkeiten können "ja" oder "löschen" sein. HideDialogItem 512 verbirgt eine gegebene Dialogposition in dem gegebenen Dialog. Show- DialogItem 514 zeigt die gegebene Dialogposition in dem gegebenen Dialog. DrawDialog 516 zeichnet jede Position in dem Dialog. UpdateDialog 518 zeichnet jede Position in dem Dialog, die innerhalb des gegebenen Aktualisierungsbereichs liegt. Der Aktualisierungsbereich ist der Bereich auf dem Bildschirm, in dem sichtbare Elemente neu gezeichnet werden müssen. FindDialogItem 520 gibt die erste Dialogposition zurück, deren Rechteck den gegebenen Punkt einschließt. GetDialogItemCommon 522 ist gemeinsamer Code zum Holen einer Dialogposition. Diese wird aufgerufen, um eine ein zelne DITL-Position zu holen. GetCompleteItemRect 524 gibt das Rechteck des ganzen Zeichnungsbereichs bei einer gegebenen bestimmten Position zurück. NextDialogItem 526 springt zur nächsten Dialogposition vor der an den Dialogverwalter übergebenen. Diese Funktion nimmt an, daß an den Dialogverwalter eine gültige DITL-Position übergeben wurde. FirstDialogItem 528 bestimmt die erste Position in der Positionsliste des Dialogs. InitDialogItem 530 initialisiert die gegebene Dialogposition in geeigneter Weise. DisposeDialogItem 532 beseitigt die gegebene Dialogposition. InitControlItem 534 initialisiert die gegebene Steuerdialogposition. GetItemListCopy 536 holt eine Kopie der Positionsliste für das gegebene DITL. SetupItemList 538 lädt das DITL-Betriebsmittel neu, falls es geräumt wurde und hält es fest (so daß es im Speicher nicht herumbewegt werden kann). DoneWithItemList 540 wird aufgerufen, wenn der Dialogverwalter das Arbeiten mit dem DITL abgeschlossen hat. Das Festhalten des DITL wird aufgehoben. FrameDialog- Item 542 ordnet ein gerahmtes rundes Rechteck um die Dialogposition an. DoForEachItem 544 läuft zyklisch durch die Positionsliste (DITL) und wendet die gegebene Funktion auf jede Position an. DrawDialogItem 546 zeichnet eine gegebene Dialogposition in dem gegebenen Dialog. Update- DialogItem 548 zeichnet eine gegebene Dialogposition neu, falls sie im gegebenen Aktualisierungsbereich liegt. Set-DialogItemKeyboardFocus 550 setzt den Zielbereich der Tastatur auf die gegebene Dialogposition. UnsetDialogItem- KeyboardFocus 552 hebt das Zielen der Tastatur auf die gegebene Dialogposition auf. GetDialogKeyboardFocusItem 554 gibt die aktuelle Tastaturzielposition im Dialog zurück. Falls auf keine gezielt wird, wird nach der ersten Position in der DITL gesucht, auf die eine Tastatur zeigen kann.
Weiter unten wird der Pseudocode für die Routine Draw- DialogItem angegeben:

VIII. Editieren einer Dialogposition

Das Editieren einer Dialogposition ist als das Ändern der den Status der Position definierenden Daten, beispielsweise das Ändern statischen Texts, von Positionskoordinaten, von Fonts, von Farben usw., definiert. Dialogpositionen können auf mindestens zwei verschiedene Arten editiert werden. Bei der ersten wird ein Betriebsmittel unter Verwendung von Quellcode erzeugt, wie in dem Code gezeigt ist, der das Betriebsmittel für das oben gezeigte GroupingRect darstellt. Das Dialogkästchen kann unter Verwendung des Texteditors editiert werden, um den Quellcode zu editieren und diesen dann neu zu kompilieren. Der Quellcode für die Dialogposition und alle anderen Betriebsmittel ist vom Quellcode für die Anwendung unabhängig.
Ein zweites Verfahren zum Editieren von Dialogen beinhaltet das Erzeugen und Editieren von Betriebsmitteln mit einem interaktiven graphikorientierten Betriebsmitteleditor, wie beispielsweise ResEditTM von Apple Computer. Eine detailliertere Beschreibung von ResEditTM kann in "ResEditTM Reference For ResEdit version 2.1", 1991, Addison-Wesley Publishing Company, gefunden werden, worauf hiermit verwiesen sei.
ResEditTM ist eine Anwendung, die ein Betriebsmittel lesen kann und dem Benutzer dann ein Dialogfenster liefert, das die Daten innerhalb des Betriebsmittels darbietet. Der Benutzer kann die Daten in dem Betriebsmittel unter Verwendung des Dialogfensters editieren.
Wenn ein DLOG-Betriebsmittel editiert wird, zeigt ResEditTM ein Fenster oder ein Dialogkästchen 600 an, wie in Fig. 16 dargestellt ist. Oben am Fenster 600 befindet sich eine Bildliste 602 der für das Dialogkästchen wählbaren Fensterstile. Darunter befindet sich ein Minibildschirm 604, der ein kleines Bild 606 des Dialogkästchens zeigt. Die Koordinaten oben 608, links 610, unten 612, rechts 614 entsprechen einem Rechteck 202 im in Fig. 6 dargestellten Dialogbetriebsmittel. DITL ID 616 entspricht der Positionslistenkennung 216 im Dialogbetriebsmittel 200 aus Fig. 6. Sichtbar 618 entspricht der Sichtbarkeit 206 im Dialogbetriebsmittel 200 aus Fig. 6. Ein Schließkästchen 620 entspricht dem Schließkästchen 210 im Dialogbetriebsmittel 200 aus Fig. 6.
Wenn ein DLOG-Betriebsmittel in ResEditTM angezeigt wird, erscheint ein entsprechendes Menü. Dieses Menü 630 ist in Fig. 16 dargestellt. "Lege Eigenschaften von "DLOG" fest" ruft ein in Fig. 18 dargestelltes Dialogkästchen 640 auf, das es dem Benutzer ermöglicht, das Fenster zu betiteln und seine refCon und procID festzulegen. Falls die procID keinem der Bilder oben auf dem Hauptfenster zugeordnet ist, wird keines dieser Bilder ausgewählt.
"Vorbetrachtung bei der vollen Größe" zeigt die Betriebsmittelgröße als Normaldarstellung an.
"Automatische Positionsfestlegung" ermöglicht es dem System, ein Fenster automatisch zu positionieren, wenn es gezeichnet wird.
"Verwenden Sie nie ein wahlfreies "WDEF" zum Zeichnen" bewirkt, wenn es wahr ist (Standard), daß das Betriebsmittel unabhängig von dem der procID zugewiesenen Wert mit dem Standard-"WDEF"-Betriebsmittel von der Systemdatei gezeichnet wird.
"Zeige Höhe und Breite an" ändert die editierbaren Felder (oben, unten, links, rechts) unten auf dem Fenster, um relative Größenpositionsinformationen 2u zeigen.
"Zeige unten und rechts an" ändert die editierbaren Felder (links, rechts) unten auf dem Fenster, um absolute Größen- /Positionsinformationen zu zeigen.
"Verwende Farbwähler" ermöglicht es dem Benutzer, einen automatischen Farbwähler zum Definieren der Farben der verschiedenen Teile des Betriebsmittels zu verwenden. Der Farbwähler ist optional und nicht erforderlich.
Wenn sich ein Benutzer mit dem in Fig. 16 dargestellten Fenster 600 austauscht, kann er den DITL-Betriebsmitteleditor öffnen, indem er auf das Bild 652 des Dialogkästchens im DLOG-Betriebsmitteleditor doppelklickt. Alternativ kann der DITL-Betriebsmitteleditor direkt aufgerufen werden. Wenn der DITL-Betriebsmitteleditor 654 (Fig. 19) aufgerufen wird, zeigt er ein Bild der Positionen aus der Liste so, wie sie in einem Dialogkästchen angezeigt werden. Wenn eine Position ausgewählt wird, wird ein gepunktetes Rechteck um sie gezeichnet. Das Rechteck weist in seiner unteren rechten Ecke ein Größenkästchen auf, so daß die Größe des Rechtecks geändert werden kann. Der DITL-Editor verwendet den Dialogverwalter zum Anzeigen der DITL- Betriebsmittel. Hierdurch wird gewährleistet, daß die Positionen, wenn die Anwendung sie zeigt, genauso aussehen, wie in ResEditTM. Zum Erzeugen einer neuen Position zieht der Benutzer den gewünschten Typ aus der Positionspalette 655. Zum Editieren einer existierenden Position doppelklickt der Benutzer auf die Position oder wählt die Position aus und drückt die Rücksprungtaste. Wenn eine Position ausgewählt wird, richtet ResEditTM den in Fig. 20 als 660 dargestellten Positionseditor ein. Im Fall des Positionseditors 660 doppelklickt der Benutzer auf die im DITL- Betriebsmitteleditor mit der Bezugszahl 655 und im DLOG- Bild mit der Bezugszahl 658 bezeichnete Position 9. Die Position 9 ist ein statischer Text (StaticText).
Wenn der Benutzer auf irgendeine der Positionen doppelklickt, wird ein Positionseditor für diese Position eingerichtet. Jeder Positionstyp hat seinen eigenen Positionseditor. Dies bedeutet, daß es einen Tastenpositionseditor, einen Anwählkästhen-Positionseditor, einen Funktasteneditor usw. gibt. Dies liegt daran, daß Taste, Anwählkästchen und Funktaste vordefinierte Positionen sind und daß ResEditTM zum Editieren dieser Positionen programmiert werden kann. Falls die Position jedoch ein IDO ist, kennt ResEditTM die Struktur, das Verhalten oder die Definition des IDOs nicht. Daher weist ResEditTM keinen Positionseditor für ein IDO auf. Demgemäß muß in jedem IDO sein eigener Editor eingebettet sein. Dies wird weiter unten erörtert.
Fig. 20 betrachtend sei bemerkt, daß der Benutzer die Rechteckwerte durch Manipulieren der Zahlen in den Kästchen 662 editieren kann. Zusätzlich kann der Text durch Bewegen des Cursors in ein Kästchen 664 und mit der Tastatur durch Eintippen neuen Texts editiert werden. Wenn der DITL- Betriebsmitteleditor 654 aus Fig. 19 verwendet wird, hat der Benutzer ein in Fig. 21 dargestelltes DITL-Menü. Das DITL-Menü 670 enthält die folgenden Befehle:
"Numeriere Positionen um" ermöglicht es einem Benutzer, Positionen im "DITL"-Betriebsmittel umzuordnen.
"Lege Positionsnummer fest..." ermöglicht es einem Benutzer, eine neue Nummer für eine gewählte Position zu spezifizieren. Möglicherweise müssen einige der Positionen umnumeriert werden.
"Wähle Positionsnummer..." ermöglicht es einem Benutzer, eine Position durch Spezifizieren ihrer Nummer auszuwählen. Dies ist für Positionen nützlich, die von anderen Positionen überdeckt sind oder sich außerhalb des Fensters befinden. Sobald eine Position ausgewählt wurde, kann sie durch Drücken der Rücksprungtaste geöffnet werden.
"Zeige Positionsnummern" legt die Anzeige so fest, daß die Nummer jeder Position im "DITL"-Betriebsmittel gezeigt wird.
"Richte auf das Gitter aus" richtet die Positionen auf einem unsichtbaren Gitter aus, dessen Größe standardmäßig 10 mal 10 Pixel beträgt. Falls der Ort der Position geändert wird, während "Richte auf das Gitter aus" eingeschal tet ist, wird der Ort so angepaßt, daß die obere linke Ecke auf dem Gitterpunkt liegt, der dem gegebenen Ort am nächsten ist. Falls die Größe einer Position geändert wird, ist sie so eingeschränkt, daß sie in jeder Dimension ein Vielfaches der aktuellen Gittereinstellung ist.
"Gittereinstellungen..." ermöglicht das Definieren der horizontalen und der vertikalen Gittergröße. Diese betragen beide standardmäßig 10 Pixel.
"Zeige alle Positionen" paßt die Fenstergröße so an, daß alle Positionen in der Positionsliste in dem Fenster sichtbar sind (oder er macht das Fenster so groß, wie es die aktuelle Bildschirmgröße ermöglicht, falls der Bildschirm kleiner ist). Dieser Befehl ist ausschließlich der Bequemlichkeit halber vorhanden, wenn die Dialogpositionen editiert werden.
"Betrachte als..." ruft ein Dialogkästchen auf, das das Definieren des Schriftbilds und der Größe, in denen Edit- Text- und StaticText-Positionen im Editor dargestellt werden, ermöglicht. Dieser Befehl ändert das Betriebsmittel selbst tatsächlich nicht. Es ist nützlich, falls ein Benutzer ein Dialogkästchen entwickelt, daß unter Verwendung eines Fonts dargestellt werden soll, der sich vom Standardfont des Editors, der 12-Punkt-Chicago ist, unterscheidet.
"Ballonhilfe..." ruft ein Dialogkästchen mit Positionen auf, die die Ballonhilfe in der Systemsoftware betreffen.
Hinsichtlich des Editierens eines IDOs besteht das Problem darin, daß ResEditTM die Struktur eines IDOs nicht kennt. Demgemäß weiß ResEditTM nicht, wie ein IDO zu editieren ist. Die Lösung besteht darin, daß die IDOs Verfahren enthalten müssen, die ResEditTM mitteilen, wie das IDO editiert werden soll. Eines dieser Verfahren ist beispielsweise EditStaticData. Weiter unten ist ein Pseudocode für das Verfahren EditStaticData angegeben.
Nach den verschiedenen Zeilen von Pseudocode ist in Klammern eine Nummer eingeschlossen. Diese Nummer entspricht dem Schritt im Flußdiagramm aus Fig. 22. Der erste Schritt des Verfahrens besteht darin, einen Dialog zu erzeugen, um die statischen Daten (StaticData) vom Benutzer zu holen (700). Das Verfahren erzeugt dann (702) ein Dialogkästchen 702a, das ein Rechteck 702b zeigt und darin eine vordefinierte Textzeichenkette 702e aufweist. An diesem Punkt kann der Benutzer den Text 702e löschen und neuen Text eintippen. Wenn der Benutzer das Eingeben von Informationen abgeschlossen hat, kann er eine von zwei Tasten, nämlich die OK-Taste 702c oder die Löschtaste 702d auswählen. Durch Drücken von einer der beiden Tasten setzt der Benutzer das Dialogkästchen ab (704). Falls der Benutzer Löschen drückt (710), werden die vom Benutzer vorgenommenen Editierungen nicht gespeichert. Falls der Benutzer OK drückt (706), werden die Eingaben des Benutzers gespeichert (708). Wenn die Position beim nächsten Mal aufgerufen wird, erscheint der vom Benutzer eingegebene Text im Dialogkästchen. Schließlich wird das Verfahren abgeschlossen (712).
Alle Befehle zum Ausführen dieser Editierungen werden im EditStaticData-Verfahren angetroffen. Falls ResEditTM versucht, ein IDO zu editieren, sieht ResEditTM, daß es ein IDO ist und übergibt die Steuerung an das richtige Verfahren. Andere Verfahren würden verwendet werden, um andere Aspekte verschiedener Positionen zu editieren. Ein Fachmann wird in der Lage sein, die oben angegebene Beschreibung zum Erzeugen anderer Typen von Editierverfahren zu verwenden.
Die vorhergehende Beschreibung der bevorzugten Ausführungsform der Erfindung wurde zur Veranschaulichung und Beschreibung gegeben. Sie ist nicht als umfassend oder die Erfindung auf die genaue offenbarte Form einschränkend vorgesehen, und es sind in Anbetracht der oben angegebenen Lehren offensichtlich zahlreiche Modifikationen und Abänderungen möglich. Es ist vorgesehen, daß der Schutzumfang der Erfindung durch die anhängigen Ansprüche definiert ist.

Claims

1. Computerimplementiertes Verfahren zum Verwalten von Positionen in einer Dialogbox, mit den folgenden Schritten:

Ausführen einer die Dialogbox aufrufenden Anweisung, wobei das Verfahren gekennzeichnet ist durch die folgenden Schritte:

Verwenden eines Dialogverwalters (446), um auf eine Liste der Positionen (430) zuzugreifen, wobei die Liste einen ersten Verweis bzw. Zeiger (434) zu einer objektorientierten Klasse (436) aufweist,

Verwenden des Dialogverwalters zum Folgen des ersten Verweises zu der objektorientierten Klasse, wobei die objektorientierte Klasse eine Definition einer ersten Position darstellt, und

Verwalten der ersten Position unter Verwendung des Dialogverwalters und basierend auf einem Exemplar (448) der objektorientierten Klasse.

2. Verfahren nach Anspruch 1, das des weiteren die folgenden Schritte aufweist: Warten auf ein Zeichenereignis, und Ausführen eines Zeichenverfahrens als Reaktion auf das Zeichenereignis ohne Ausführen anderer Verfahren in der Klasse.

3. Verfahren nach Anspruch 1, das des weiteren die folgenden Schritte aufweist: Warten auf ein Editierungsereignis, und Ausführen eines Editierungsverfahrens als Reaktion auf das Editierungsereignis ohne Ausführen anderer Verfahren in der Klasse.

4. Verfahren nach Anspruch 1, das des weiteren die folgenden Schritte aufweist: Warten auf ein erstes der ersten Position zugeordnetes Ereignis, Eingeben des Exemplars der Klasse an einem ersten Eingabepunkt als Reaktion auf das erste Ereignis, und Ausführen eines ersten Verfahrens in dieser Klasse als Reaktion auf das erste Ereignis, wobei der erste Eingabepunkt mit dem ersten Verfahren zugeordnet ist.

5. Verfahren nach Anspruch 1, das des weiteren die folgenden Schritte aufweist: Weitergabe der Steuerung von dem Dialogverwalter an eine Anwendung nachdem die Dialogbox erzeugt wurde, Weitergabe der Steuerung von der Anwendung an den Dialogverwalter, wenn ein Ereignis eintritt, und Zugreifen des Dialogverwalters auf ein Verfahren des Exemplars der Klasse, wobei das Verfahren relevant ist für das Ereignis.

6. Verfahren nach Anspruch 1, bei dem: der Schritt des Verwendens des Dialogverwalters zum Zugriff die folgenden Schritte aufweist: Lesen eines die Dialogbox betreffenden Betriebsmittels DLOG, und Lesen eines Betriebsmittels DITL zum Anzeigen einer Dialogpositionenliste, auf das von dem DLOG-Betriebsmittel verwiesen wird.

7. Verfahren nach Anspruch 6, bei dem: das DLOG-Betriebsmittel und das DITL-Betriebsmittel in einem einzelnen Betriebsmittel sind.

8. Verfahren nach Anspruch 6, bei dem: das DLOG-Betriebsmittel Informationen über die Dialogbox und einen Verweis auf das DITL enthält.

9. Verfahren nach Anspruch 6, bei dem: das DITL folgendes enthält: die in der Dialogbox anzuzeigende Positionenliste, eine Stelle für jede Position, und einen Klassennamen für zumindest eine Teilmenge von Positionen.

10. Verfahren nach Anspruch 1, bei dem: die Klasse Teil einer objektorientierten Klassenstruktur ist.

11. Verfahren nach Anspruch 1, das des weiteren die folgenden Schritte aufweist: Verwenden des Dialogverwalters zum Folgen eines zweiten Verweises zu einer Definition einer zweiten Position, wobei die Definition nicht Teil einer objektorientierten Klassenstruktur ist, und Verwalten der zweiten Position unter Verwendung des Dialogverwalters und basierend auf der Definition der zweiten Position.

12. Vorrichtung, die eine Dialogbox verwendet und folgendes umfaßt: einen Prozessor (110), einen in Verbindung mit dem Prozessor stehenden Speicher (114, 115, 116), eine in Verbindung mit dem Prozessor stehende Speichereinrichtung (115), wobei in der Speichereinrichtung Programmcode zur Programmierung des Prozessors zum Durchführen der folgenden Schritte gespeichert ist: Ausführen einer die Dialogbox aufrufenden Anweisung, wobei die Vorrichtung dadurch gekennzeichnet ist, daß in der Speichereinrichtung Programmcode zum Programmieren des Prozessors zum Durchführen der folgenden Schritte gespeichert ist: Verwenden eines Dialogverwalters zum Zugreifen auf eine Liste der Positionen, wobei die Liste einen ersten Verweis auf eine objektorientierte Klasse beinhaltet, Verwenden des Dialogverwalters zum Folgen des ersten Verweises zu der objektorientierten Klasse, wobei die objektorientierte Klasse eine Definition einer ersten Position darstellt, und Verwalten der ersten Position unter Verwendung des Dialogverwalters und basierend auf einem Exemplar der objektorientierten Klasse, ein in Verbindung mit dem Prozessor stehendes Anzeigegerät (118), und eine in Verbindung mit dem Prozessor stehende Eingabeeinrichtung (112, 113).

13. Vorrichtung nach Anspruch 12, bei der das Verfahren des weiteren die folgenden Schritte aufweist: Warten auf ein erstes der ersten Position zugeordnetes Ereignis, Eingabe des Exemplars der Klasse an einem ersten Eingabepunkt als Reaktion auf das erste Ereignis, und Ausführen eines ersten Verfahrens in der Klasse als Reaktion auf das erste Ereignis, wobei der erste Eingabepunkt dem ersten Verfahren zugeordnet ist.

14. Vorrichtung nach Anspruch 12, bei der das Verfahren des weiteren die folgenden Schritte aufweist: Weitergabe der Steuerung von dem Dialogverwalter an eine Anwendung nachdem die Dialogbox erzeugt wurde, Weitergabe der Steuerung von der Anwendung an den Dialogverwalter im Falle eines Ereignisses, und Zugreifen des Dialogverwalters auf ein Verfahren des Exemplars der Klasse, wobei das Verfahren relevant ist für das Ereignis.

15. Vorrichtung nach Anspruch 12, bei der: der Schritt des Verwendens des Dialogverwalters zum Zugriff die folgenden Schritte aufweist: Lesen eines der Dialogbox zugeordneten Betriebsmittels DLOG, und Lesen eines Betriebsmittels DITL zum Anzeigen einer Dialogpositionenliste, auf das von dem DLOG-Betriebsmittel verwiesen wird.