DE69410483T2 - Objektorientiertes aufgabensicheres rahmenwerk - Google Patents

Description

Gebiet der Erfindung
• Diese Erfindung betrifft im allgemeinen Verbesserungen bei Computersystemen und insbesondere eine Betriebssystemsoftware zur Verwaltung von Zeichenbereichen, die als Ansichten bezeichnet werden, innerhalb eines Fensterdarstellungsbereiches in einer Grafischen Benutzerschnittstelle.
Hintergrund der Erfindung
• Einer der wichtigsten Aspekte eines modernen Computersystems ist die Schnittstelle zwischen dem menschlichen Benutzer und der Maschine. Die früheste und am weitesten verbreitete Schnittstelle war textbasiert, wobei ein Benutzer mit der Maschine durch das Eintippen von Textzeichen auf einer Tastatur kommunizierte, und die Maschine mit dem Benutzer durch die Darstellung von Textzeichen an einem Bildschirm kommunizierte. In letzter Zeit fanden Grafische Benutzerschnittstellen weitere Verbreitung, bei denen die Maschine mit einem Benutzer durch Darstellung von Grafiken einschließlich Text und Bildern an einem Bildschirm kommuniziert, und der Benutzer mit der Maschine sowohl durch das Eintippen von Textbefehlen als auch durch das Manipulieren der angezeigten Bilder mit einem Zeigergerät, wie zum Beispiel einer Maus, kommuniziert.
• Viele moderne Computersysteme arbeiten mit einer grafischen Benutzerschnittstelle, die als Fensterumgebung bezeichnet wird. In einer typischen Fensterumgebung ist die am Bildschirm dargestellte grafische Anzeige so angeordnet, daß sie der Oberfläche eines elektronischen "Schreib tisches" (engl. Desktop) ähnelt, und jedes Anwendungsprogramm, das am Computer läuft, wird als ein oder mehrere elektronische "Papierbögen" in rechteckigen Bereichen des Bildschirms dargestellt, die als "Fenster" bezeichnet werden.
• Jeder Fensterbereich zeigt im allgemeinen Informationen an, die von dem dazugehörigen Anwendungsprogramm erzeugt werden, und es können mehrere Fensterregionen gleichzeitig am Desktop vorhanden sein, die jeweils Informationen darstellen, welche von einem unterschiedlichen Anwendungsprogramm erzeugt werden. Ein Anwendungsprogramm stellt dem Benutzer Informationen durch die einzelnen Fenster zur Verfügung, indem es Bilder, Grafiken oder Text innerhalb der Fensterregion zeichnet oder "malt". Der Benutzer wiederum kommuniziert mit dem Anwendungsprogramm, indem er mit einem Cursor, der von einem Zeigergerät gesteuert wird, auf Objekte in der Fensterregion "zeigt" und die Objekte damit manipuliert oder bewegt, und auch, indem er Informationen über die Tastatur eintippt. Die Fensterregionen können am Bildschirm auch verschoben werden, und ihre Größe und ihr Erscheinungsbild können verändert werden, so daß der Benutzer den Desktop auf komfortable Weise einrichten kann.
• Jede der Fensterregionen umfaßt typischerweise auch eine Anzahl an grafischen Standardobjekten, wie zum Beispiel Boxen zur Größenveränderung, Schaltflächen und Rollbalken. Diese Merkmale stellen Benutzerschnittstelleneinrichtungen dar, auf die der Benutzer mit dem Cursor klicken kann, um sie auszuwählen und zu manipulieren. Wenn die Einrichtungen ausgewählt oder manipuliert werden, wird das darunterliegende Anwendungsprogramm vom Fenstersystem darüber informiert, daß die Steuerung vom Benutzer manipuliert wurde.
• Im allgemeinen ist die oben beschriebene Fensterumgebung Bestandteil des Computerbetriebsystems. Das Betriebssystem umfaßt typischerweise auch eine Sammlung von Hilfsprogrammen, die das Computersystem in die Lage verset zen, grundlegende Operationen auszuführen, wie zum Beispiel das Speichern und Holen von Informationen auf und von einem Festplattenspeicher, und die Ausführung von Dateioperationen, einschließlich der Erstellung, Benennung und Umbenennung von Dateien, und in manchen Fällen die Ausführung von Prüfoperationen, um Fehlfunktionen zu erkennen oder zu beseitigen.
• Der letzte Teil des Computersystems wird als "Anwendungsprogramm" bezeichnet, das mit dem Betriebssystem interagiert, um einen viel höheren Grad an Funktionalität zu ermöglichen, eine bestimmte Aufgabe (Task) auszuführen und eine direkte Schnittstelle zum Benutzer zu schaffen. Das Anwendungsprogramm verwendet typischerweise die Funktionen des Betriebssystems, indem es eine Reihe von Task- Befehlen zum Betriebssystem sendet, welches dann den angeforderten Task ausführt; so könnte zum Beispiel das Anwendungsprogramm anfordern, daß das Betriebssystem bestimmte Informationen im Festplattenspeicher des Computers speichert oder Informationen an der Bildschirmanzeige darstellt.
• Fig. 1 ist eine schematische Darstellung eines typischen Computersystems des Standes der Technik, welches sowohl ein Anwendungsprogramm als auch ein Betriebssystem verwendet. Das Computersystem wird schematisch durch die Box 100 dargestellt, die Anwendung wird durch die Box 102 dargestellt, und das Betriebssystem wird durch die Box 106 dargestellt. Die zuvor beschriebene Interaktion zwischen dem Anwendungsprogramm 102 und dem Betriebssystem 106 ist schematisch durch den Pfeil 104 dargestellt. Dieses Doppelprogrammsystem wird auf vielen Computersystemen verwendet, angefangen von Mainframes bis hin zu Personalcomputern.
• Das Verfahren zur Handhabung der Bildschirmdarstellung ist jedoch von Computer zu Computer unterschiedlich, und in dieser Hinsicht repräsentiert Fig. 1 ein Personalcomputersystem des Standes der Technik. Um ein Zeichnen zu Bildschirmanzeigen zu ermöglichen, speichert das Anwendungspro gramm 102 im allgemeinen die darzustellenden Informationen (der Speichervorgang ist schematisch durch den Pfeil 108 dargestellt) in einem Bildschirmzwischenspeicher 110. Unter der Steuerung verschiedener Hardware- und Software-Komponenten im System wird der Inhalt des Bildschirmzwischenspeichers 110 aus dem Zwischenspeicher ausgelesen und, wie durch den Pfeil 114 schematisch dargestellt, dem Anzeigenadapter 112 zur Verfügung gestellt. Dir Anzeigenadapter 112 enthält Hardware und Software (manchmal in der Form von Firmware), welche die Informationen im Bildschirmzwischenspeicher 110 in eine Form umwandeln, die dazu verwendet werden kann, um den Anzeigenmonitor 118 anzusteuern, der über das Kabel 116 mit dem Anzeigenadapter 112 verbunden ist.
• Die in Fig. 1 dargestellte Konfiguration des Standes der Technik arbeitet gut in einem System, in dem jeweils nur ein einzelnes Anwendungsprogramm mit einem einzelnen Ausführungs-Thread (Prozeßstrang) 102 läuft. Dieses einfache System funktioniert richtig, weil der Thread 102 des einzelnen Anwendungsprogramms Informationen in jeden beliebigen Bereich des gesamten Bildschirmzwischenspeicherbereiches 110 schreiben kann, ohne dadurch Probleme bei der Darstellung zu verursachen. Wenn jedoch die in Fig. 1 dargestellte Konfiguration in einem Computersystem verwendet wird, in dem mehr als ein Anwendungsprogramm oder mehr als ein Ausführungs-Thread in diesem Anwendungsprogramm 102 gleichzeitig ausgeführt werden kann (zum Beispiel in einem "Multitasking"-Computersystem), kann es zu Darstellungsproblemen kommen. Wenn insbesondere jeder Thread in jedem Anwendungsprogramm Zugriff auf den gesamten Bildschirmzwischenspeicher 110 hat, kann es im Falle eines Fehlens einer direkten Kommunikation zwischen Threads und Anwendungen dazu kommen, daß ein Thread einen Abschnitt des Bildschirmzwischenspeichers überschreibt, der von einem anderen Thread verwendet wird, was dazu führt, daß die von einem Thread erzeugte Anzeige von der von einem anderen Thread erzeugten Anzeige überschrieben wird.
• Demgemäß wurden Mechanismen entwickelt, um die Ausführung der Anwendungen sowie der Ausführungs-Threads innerhalb der Anwendungen zu koordinieren, um sicherzustellen, daß jeder Anwendungs-Thread nur auf einen Abschnitt des Bildschirmzwischenspeichers beschränkt wurde, wodurch die anderen Anzeigen getrennt wurden. Diese Koordinierung wurde jedoch in solchen Systemen, in denen mehrere "Fenster" mit mehreren Threads erlaubt wurden, die in diese Fenster zeichneten, sehr kompliziert. Das Problem wurde in zwei Teile unterteilt: das Verwalten der Fenster und ihres Anzeigenbereiches (Anwendungsprogramme), und das Verwalten der Ausführungs-Threads innerhalb dieser Anwendungen. Der Fensterverwalter (Window Manager) isl: mit der Aufgabe der Koordination zwischen Anwendungen und ihren Fenstern betraut. Das Ansichtssystem (View System) ist mit der Koordinierung von Threads innerhalb der Anwendungen und ihres/ihrer Fenster(s) betraut. Jedes Fenster ist in eine Hierarchie von Zeichenbereichen unterteilt, die als "Ansichten" bezeichnet werden, und bestimmten Ausführungs- Threads innerhalb eines bestimmten Anwendungsprogramms zugeordnet sind.
• Wenn das Anwendungsfenster so angeordnet wird, daß sich Ansichten zu "überlappen" scheinen, bedeckt und verbirgt eine Ansicht, die im Fenster "vor" einem anderen Fenster erscheint, das darunterliegende Fenster. Somit kann außer der vordersten Ansicht nur ein Teil der darunterliegenden Ansichten am Bildschirm gezeichnet werden und in der Folge zu einer bestimmten Zeit "sichtbar" sein. Weil desweiteren die Ansicht vom Benutzer verschoben oder in ihrer Größe verändert werden kann, ändert sich auch der Abschnitt einer jeden Ansicht, wenn andere Ansichten hinzugefügt, entfernt, verschoben oder in ihrer Größe verändert werden. Somit ändert sich auch der Abschnitt des Fensters, welches jedem Thread zugewiesen ist, wenn Ansichten von anderen Threads hinzugefügt, entfernt, verschoben oder in ihrer Größe verändert werden.
• Um auf wirkungsvolle Weise die Änderungen an den Fenstern verwalten zu können, was notwendig ist, um die aufgrund des Verschiebens oder der Größenveränderung von Ansichten erfolgenden raschen Bildschirmänderungen zu berücksichtigen, wurde die in Fig. 1 dargestellte Computeranordnung des Standes der Technik wie in Fig. 2 dargestellt geändert. In dieser neuen Anordnung wird das Computersystem 200 von einem oder mehreren Anwendungsprogrammen gesteuert, die einen oder mehrere Ausführungs-Threads umfassen können, von denen die Threads 202 und 216 dargestellt sind, und die gleichzeitig im Computersystem laufen können. Jeder der Threads besitzt eine Schnittstelle zum Betriebssystem 204, wie dies schematisch durch die Pfeile 206 und 220 dargestellt ist. Um jedoch Informationen am Anzeigebildschirm darzustellen, senden die Anwendungs- Threads 202 und 216 Anzeigeinformationen zu einem zentralen Ansichtssystem (View System) 218, das sich im Betriebssystem 204 befindet. Das Ansichtssystem 218 besitzt wiederum eine direkte Schnittstelle zum Bildschirmzwischenspeicher 210, wie dies schematisch durch den Pfeil 208 dargestellt ist. Der Inhalt des Bildschirmzwischenspeichers 210 wird, wie durch den Pfeil 212 angezeigt, einem Anzeigeadapter 214 zur Verfügung gestellt, der durch ein Kabel 222 mit einem Anzeigemonitor 224 verbunden ist.
• In einem solchen System ist das Ansichtssystem 218 im allgemeinen dafür verantwortlich, den gesamten Anzeigeinhalt, den der Benutzer innerhalb Eines Fensters sieht, während der Operation der Anwendungsprogramme zu warten. Da das Ansichtssystem 218 mit allen Threads innerhalb einer Anwendung in Verbindung steht, kann es eine Koordination zwischen den Threads ermöglichen, um sicherzustellen, daß sich die Anzeigen von Ansichten nicht überlappen. Daher ist es im allgemeinen die Aufgabe des Ansichtssystems, die Position und Größe der Ansicht und der Ansichtsbereiche zu verfolgen, die gezeichnet und neu gezeichnet werden müssen, wenn Ansichten und Fenster verschoben werden.
• Das Ansichtssystem 218 empfängt Anzeigeanforderungen von jedem der Anwendungs-Threads 202 und 216. Da jedoch nur das Ansichtssystem 218 eine Schnittstelle zum Bildschirmzwischenspeicher 210 besitzt, kann es die jeweiligen Bereiche des Bildschirmzwischenspeichers 210 für jede Anwendung zuordnen und sicherstellen, daß kein Thread irrtümlicherweise die von einem anderen Thread Erzeugte Anzeige überschreibt. Eine Reihe unterschiedlicher Fenster-Umgebungen ist kommerziell erhältlich, welche die in Fig. 2 dargestellte Anordnung verwenden. Dazu gehören die Betriebsumgebung X/Window, die von der Microsoft Corporation entwickelte grafische Benutzerschnittstelle WINDOWS, sowie der von International Business Machines Corporation entwickelte OS/2 Presentation Manager.
• Jede dieser Fenster-Umgebungen besitzt ihre eigene interne Software-Architektur, aber alle diese Architekturen können einer Gruppe zugeordnet werden, die ein Mehrschicht- Modell (Multilayer-Modell) verwendet, das jenen Mehrschicht-Modellen ähnelt, die zur Beschreibung von Computernetzwerk-Software verwendet werden. Ein typisches Mehrschicht-Modell umfaßt die folgenden Schichten:
• Benutzerschnittstelle
• Fensterverwalter
• Betriebsmittelverwaltung und Kommunikation
• Komponententreibersoftware
• Computer-Hardware
• wobei sich der Begriff "Fensterumgebung" gemeinsam auf alle oben genannten Schichten bezieht.
• Die niedrigste Ebene bzw. die Computer-Hardware-Ebene umfaßt den grundlegenden Computer und die mit ihm in Verbindung stehenden Eingabe- und Ausgabegeräte, einschließlich Anzeigenmonitore, Tastaturen, Zeigergeräte, wie zum Beispiel Mäuse und Trackballs, und andere Standardkomponenten, einschließlich Drucker und Plattenlaufwerke. Die nächste Ebene bzw. die "Komponententreibersoftware"-Ebene besteht aus geräteabhängiger Software, welche die Befehle und Signale erzeugt, die für den Betrieb der verschiedenen Hardware-Komponenten erforderlich sind. Die Betriebsmittelverwaltungs- und Kommunikationsschicht besitzt eine Schnittstelle zu den Komponententreibern und umfaßt Software-Routinen, die Ressourcen zuweisen, zwischen Anwendungen kommunizieren und Kommunikationen mehrfach ausnutzen, die von höheren Schichten für die darunterliegenden Schichten erzeugt werden. Das Ansichtssystem verwaltet die Benutzerschnittstelle zu den grundlegenden Zeichenoperationen, wie zum Beispiel das Verschieben und Größenverändern von Ansichten, das Aktivieren oder Deaktivieren von Ansichten und das Neuzeichnen und Neumalen von Ansichten. Die letzte Benutzerschnittstellenschicht stellt Systemeinrichtungen hoher Ebene zur Verfügung, welche die verschiedenen Steuerelemente (Schaltflächen, Bildlauffelder, Felder und andere Steuerelemente) implementiert, die Anwendungsprogramme benutzen, um eine vollständige Benutzerschnittstelle zu entwickeln.
• Der Artikel mit dem Titel "Distributed Programming in GARF", Obiect-Based Distributed Programming, ECCOP' 93 Workshop, 26. Juli 1993, Seiten 225-239, diskutiert GARF, eine objektorientierte Programmierumgrebung, die darauf abzielt, die Konstruktion zuverlässicrer verteilter Anwendungen zu unterstützen. Ihr rechenbetontes Modell basiert auf zwei Programmierebenen: der Funktionsebene und der Verhaltensebene. Auf der Funktionsebene werden Software-Funktionen mit Hilfe passiver Objekte, sogenannter Datenobjekte, in einer zentralisierten, flüchtigen und fehler freien Umgebung beschrieben. Auf der Verhaltensebene werden Datenobjekte dynamisch an Einkapsler und Mailer gebunden, die Verteilung, Gleichzeitigkeit, Persistenz und Fehlertoleranz unterstützen. Einkapsler hüllen Datenobjekte ein, indem sie bestimmen, wie letzere Meldungen senden und empfangen, während Mailer die Kommunikation zwischen den Einkapslern ausführen.
• Demgemäß ist es eine Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren gemäß der Definition im angehängten Anspruch 1 bzw. 8 zu schaffen.
Zusammenfassung der Erfindung
• Die zuvor erwähnten Probleme werden gelöst und die zuvor erwähnten Aufgaben erreicht durch eine beispielhafte Ausführungsform der Erfindung, in der ein objektorientiertes Ansichtsrahmenwerk einen Mechanismus unterstützt, um einen multitasking-sicheren Wrapper (Umhüller) von Objekten zu schaffen, die nicht multitasking-sicher sind. Dieser Mechanismus ermöglicht es, Objekte, die nicht task-sicher sind, in einer Multitasking-Umgebung zu verwenden, ohne die Objekte modifizieren zu müssen oder die internen Funktionen der Objekte verstehen zu müssen. Dieser Mechanismus ist nicht ansichtssystemspezifisch, sondern wird vom Ansichtssystem geschaffen und verwendet, um ein solches Verhalten zu unterstützen.
Kurze Beschreibung der Zeichnungen
• Die oben genannten sowie weitere Vorteile der Erfindung können besser durch die Bezugnahme auf die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen verstanden werden, in denen:
• Fig. 1 ein schematisches Blockdiagramm eines Computersystems des Standes der Technik ist, welches die Beziehung zwischen dem Anwendungs-Thread, dem Betriebssystem, dem Bildschirmzwischenspeicher und dem Anzeigenmonitor zeigt.
• Fig. 2 ein schematisches Blockdiagramm einer Modifizierung des in Fig. 1 dargestellten Systems des Standes der Technik ist, das es mehreren Anwendungs-Threads, die gleichzeitig laufen, ermöglicht, eine Anzeigenausgabe in einem einzigen Fenster zu erzeugen.
• Fig. 3 ein schematisches Blockdiagramm eines Computersystems, wie zum Beispiel eines Personalcomputer-Systems, darstellt, auf welchem das erfinderische objektorientierte Ansichtsrahmenwerk arbeitet.
• Fig. 4 ein schematisches Blockdiagramm eines modifizierten Computersystems ist, welches die Interaktion zwischen einer Mehrzahl an Anwendungs-Threads, dem Ansichtsrahmenwerk, dem Fensterverwalter und dem Bildschirmzwischenspeicher zur Darstellung grafischer Informationen an einem Anzeigemonitor darstellt.
• Fig. 5 ein schematisches Blockdiagramm der Informationspfade ist, welche die Art und Weise veranschaulichen, in der ein Anwendungs-Thread mit dem erfinderischen objektorientierten Ansichtsrahmenwerk und danach direkt mit dem Bildschirmzwischenspeicher kommuniziert.
• Fig. 6 ein schematisches Diagramm ist, welches das typische Erscheinungsbild einer grafischen Benutzerschnittstelle zeigt, die von einem objektorientierten Ansichtsrahmenwerk unterstützt wird, wobei die Komponenten und Teile eines Fensters und der darin enthaltenen Ansichtshierarchie dargestellt werden.
• Fig. 7A und 7B die Abschnitte der Ansichtshierarchie zeigen, die neu gezeichnet werden missen, wenn die Größe einer Ansicht verändert wird.
• Fig. 8 ein veranschaulichendes Flußdiagramm eines Verfahrens ist, durch welches das objektorientierte Rahmenwerk das Aktualisieren ungültiger Bereiche an der Anzeige mit Hilfe von Hintergrund-Thread(s) unterstützt, um Informationen am Anzeigebildschirm darzustellen.
• Fig. 9 ein veranschaulichendes Flußdiagramm eines Verfahrens ist, das von dem Anwendungs-Thread verwendet wird, um ein neues Ansichtsobjekt zu erzeugen und dieses in die Ansichtshierarchie einzubauen.
• Fig. 10 ein veranschaulichendes Flußdiagramm eines Verfahrens ist, daß verwendet wird, um eine polymorphe Initialisierung und Finalisierung eines Ansichtsrahmenwerk- Objektes zu unterstützen.
• Fig. 11 ein veranschaulichendes Flußdiagramm des Verfahrens ist, durch welches ein Anwendungs-Thread Zeichenzustandsinformationen vom objektorientierten Ansichtsrahmenwerk anfordert.
• Fig. 12 ein schematisches Blockdiagramm zweier nicht geradliniger Ansichten und einer zerstückelten Ansicht innerhalb der Ansichtshierarchie ist, die vom objektorientierten Ansichtsrahmenwerk unterstützt werden.
• Fig. 13 ein schematisches Blockdiagramm der Unterstützung mehrerer Koordinatenräume durch das objektorientierte Ansichtsrahmenwerk darstellt.
• Fig. 14 ein schematisches Blockdiagramm von Ansichtsobjekten darstellt, die vom objektorientierten Ansichtsrahmenwerk nach ihrem Schwerpunkt ausgerichtet sind.
• Fig. 15 ein veranschaulichendes Flußdiagramm des Verfahrens ist, durch welches eine Ansicht durch das objektorientierte Ansichtsrahmenwerk automatisch räumlich angeordnet wird.
• Fig. 16 ein schematisches Blockdiagramm des visuellen Effektes "Magnifier View" (Vergrößerungsansicht) ist, der ein Matrixobjekt verwendet, um eine; skalierende Umwandlung an der in der Ansichtshierarchie darunterliegenden Ansicht auszuführen, wie dies vom objektorientierten Rahmenwerk unterstützt wird.
• Fig. 17 ein schematisches Blockdiagramm des vom objektorientierten Ansichtsrahmenwerk verwendeten Verfahrens ist, um eine Gruppierung miteinander in Verbindung stehen der Fenster zu ermöglichen, so daß sie als eine einzelne Schicht verschoben werden können.
• Fig. 18 ein veranschaulichendes Flußdiagramm des Verfahrens ist, durch welches ein Anwendungs-Thread ein nicht-multitaskingfähiges Objekt in einer Multitasking- Umgebung verwendet, wie dies durch das objektorientierte Ansichtsrahmenwerk ermöglicht wird.
• Fig. 19 ein veranschaulichendes Flußdiagramm des Verfahrens ist, durch welches ein Anwendungs-Thread ein Positionsereignis über das Eingabesystem und das objektorientierte Ansichtsrahmenwerk empfängt.
• Fig. 20 ein veranschaulichendes Flußdiagramm des Verfahrens ist, durch welches ein Anwendungs-Thread Änderungen im objektorientierten Ansichtsrahmenwerk in einer einzigen Stapelmeldung empfängt.
• Fig. 21 ein schematisches Blockdiagramm des Verfahrens darstellt, das vom objektorientierten Ansichtsrahmenwerk verwendet wird, um Nur-Lesen- und Lesen-Schreiben- Operationen an den Hierarchie- und Ansichtsobjekten auszuführen.
Detaillierte Beschreibung einer bevorzugten Ausführungsform der Erfindung
• Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel dem IBM PS/2 oder einem Apple MacIntosh Computer, befindet. Eine repräsentative Hardwareumgebung ist in Fig. 3 dargestellt, die eine typische Hardwarekonfiguration eines Computers 300 gemäß der vorliegenden Erfindung zeigt. Der Computer 300 wird von einer Zentraleinheit (CPU) 302 (bei der es sich um einen herkömmlichen Mikroprozessor handeln kann) gesteuert, und eine Anzahl anderer Einheiten, die alle über einen Systembus 308 miteinander verbunden sind, ist ebenfalls vorhanden, um bestimmte Aufgaben auszuführen. Wenngleich ein bestimmter Computer vielleicht nur einige der in Fig. 3 dargestellten Einheiten aufweisen oder zusätzliche Komponenten besitzen kann, welche nicht dargestellt sind, werden die meisten Computer zumindest die dargestellten Einheiten aufweisen.
• Insbesondere umfaßt der in Fig. 3 dargestellte Computer 300 einen Direktzugriffsspeicher (RAM) 306 für die zeitweilige Speicherung von Informationen, einen Nur-Lesen- Speicher (ROM) 304 für die dauerhafte Speicherung der Konfiguration des Computers und der grundlegenden Betriebsbefehle, und einen Eingabe-/Ausgabe- (E/A) Adapter 310 für den Anschluß von Peripheriegeräten, wie zum Beispiel einer Platteneinheit 313 und eines Druckers 314 am Bus 308 über die Kabel 315 bzw. 312. Es steht auch ein Benutzerschnittstellenadapter 316 für den Anschluß von Eingabegeräten, wie zum Beispiel einer Tastatur 320, und anderen bekannten Schnittstellengeräten, einschließlich Mäusen, Lautsprechern und Mikrophonen, am Bus 308 zur Verfügung. Die visuelle Ausgabe erfolgt über einen Anzeigenadapter 318, der den Bus 308 mit einem Anzeigegerät 322, wie zum Beispiel einem Videomonitor, verbindet. Auf der Workstation befindet sich eine Betriebssystemsoftware, wie zum Beispiel das Apple System/7-Betriebssystem, welches die Workstation steuert und koordiniert.
• In einer bevorzugten Ausführungsform wird die Erfindung in der C++-Programmiersprache mit Hilfe objektorientierter Programmiertechniken implementiert. C++ ist eine kompilierte Sprache, das heißt, Programme werden in einem für den Menschen leicht lesbaren Skript geschrieben, und dieses Skript wird dann von einem anderen Programm, einem sogenannten Kompilierer, bearbeitet, der einen maschinenlesbaren numerischen Code daraus erzeugt, welcher in den Computer geladen und von diesem direkt ausgeführt werden kann. Wie unten beschrieben, besitzt: die C++-Sprache bestimmte Merkmale, die es einem Softwareentwickler erlauben, Programme, die von anderen geschrieben wurden, auf einfache Weise zu verwenden und gleichzeitig eine umfangreiche Kontrolle über die Wiederverwendung der Programme zu wahren, um deren Zerstörung oder unsachgemäße Verwendung zu verhindern. Die C++-Sprache ist gut bekannt, und viele Artikel und Texte sind verfügbar, in denen diese Sprache im Detail beschrieben wird. Darüber hinaus sind C++- Kompilierer von mehreren Herstellern einschließlich Borland International, Inc. und der Microsoft Corporation kommerziell erhältlich. Aus Gründen der Verständlichkeit werden daher die Details der C++-Sprache und der Betrieb des C++- Kompilierers in diesem Dokument nicht näher behandelt.
• Wie den Fachleuten dieses Bereiches bekannt ist, umfassen die Objektorientierten Programmier- (OOP) Techniken die Definition, Erstellung, Verwendung und Zerstörung von "Objekten". Diese Objekte sind Software-Einheiten, die Datenelemente und Routinen bzw. Funktionen umfassen, welche die Datenelemente manipulieren. Die Daten und damit in Verbindung stehenden Funktionen werden von der Software als eine Einheit behandelt und können erzeugt, verwendet und gelöscht werden, als ob es sich dabei um einen einzigen Gegenstand handeln würde. Gemeinsam machen es die Daten und Funktionen den Objekten möglich, nahezu jede Echtwelt- Einheit hinsichtlich ihrer Merkmale, welche von den Datenelementen repräsentiert werden, und ihrem Verhalten, welches von ihren Datenmanipulationsfunktionen repräsentiert wird, zu modellieren. Auf diese Weise können Objekte konkrete Dinge wie Personen und Computer modellieren, und sie können auch abstrakte Begriffe wie Zahlen oder geometrische Begriffe modellieren.
• Objekte werden durch Erzeugung von "Klassen" definiert, die selbst keine Objekte sind, aber die als Vorlagen dienen, welche dem Kompilierer mitteilen, wie das eigentliche Objekt zu konstruieren ist. Eine Klasse kann zum Beispiel die Anzahl und Art der Datenvariablen und die Schritte festlegen, die mit den Funktionen, welche die Daten manipulieren, im Zusammenhang stehen. Ein Objekt wird eigentlich im Programm mittels einer speziellen Funktion erstellt, die als Konstruktor bezeichnet wird, und welche die entsprechende Klassendefinition und zusätzliche Informationen, wie zum Beispiel Argumente, verwendet, die während der Objekterstellung zur Verfügung gestellt werden, um das Objekt zu konstruieren. Auf ähnliche Weise werden Objekte von einer speziellen Funktion, die als Destruktor bezeichnet wird, zerstört. Objekte können durch Verwendung ihrer Daten und Aufruf ihrer Funktionen verwendet werden.
• Die Hauptvorteile der objektorientierten Programmiertechniken ergeben sich aus drei grundlegenden Prinzipien: Einkapselung, Polymorphismus und Vererbung. Insbesondere können Objekte entsprechend konstruiert werden, um die gesamte interne Datenstruktur und die internen Funktionen oder einen Teil davon zu verstecken oder einzukapseln. Insbesondere kann ein Programmentwickler während der Programmerstellung Objekte definieren, in denen alle oder einige der Datenvariablen und alle oder einige der damit im Zusammenhang stehenden Funktionen als "privat" oder zur ausschließlichen Verwendung durch das Objekt selbst erklärt werden. Andere Daten oder Funktionen können als "öffentlich" erklärt oder für die Verwendung durch andere Programme freigegeben werden. Der Zugriff auf die privaten Variablen durch andere Programme kann durch das Festlegen öffentlicher Funktionen für ein Objekt gesteuert werden, welche auf die privaten Daten des Objektes zugreifen. Die öffentlichen Funktionen bilden eine kontrollierte und konsistente Schnittstelle zwischen den privaten Daten und der "Außenwelt". Jeder Versuch, einen Programmcode zu schreiben, der direkt auf die privaten Variablen zugreift; führt dazu, daß der Kompilierer einen Fehler während der Programmkompilierung erzeugt, der den Kompilierungsvorgang stoppt und verhindert, daß das Programm ausgeführt werden kann.
• Polymorphismus ist ein Konzept, das es Objekten und Funktionen, welche dasselbe Gesamtformat aufweisen, aber mit unterschiedlichen Daten arbeiten, erlaubt, auf unter schiedliche Weise zu arbeiten, um konsistente Ergebnisse zu produzieren. Zum Beispiel kann eine Additionsfunktion als Variable A plus Variable B (A+B) definiert werden, und dieses selbe Format kann unabhängig davon verwendet werden, ob es sich bei A und B um Zahlen, Zeichen oder Dollar und Cent handelt. Der eigentliche Programmcode jedoch, der die Addition ausführt, kann sich je nach Art der Variablen, die A und B enthalten, stark unterscheiden. Polymorphismus ermöglicht das Schreiben dreier separater Funktionsdefinitionen, nämlich eine für jede Variablenart (Zahlen, Zeichen und Dollar). Nachdem die Funktionen definiert wurden, kann ein Programm später durch sein gemeinsames Format (A+B) auf die Additionsfunktion Bezug nehmen, und während der Kompilierung wird der C++-Kompilierer durch Überprüfung der Variablentypen bestimmen, welche der drei Funktionen nun tatsächlich verwendet wird. Daraufhin wird der Kompilierer den entsprechenden Funktionscode ersetzen. Polymorphismus ermöglicht es, daß ähnliche Funktienen, die zu analogen Ergebnissen führen, im Quellcode des Programms "zusammengefaßt" werden, um einen logischeren und klareren Programmablauf zu erzeugen.
• Das dritte Prinzip, das der objektorientierten Programmierung zugrunde liegt, ist die Vererbung, die es Programmentwicklern erlaubt, bereits bestehende Programme auf einfache Art und Weise wiederzuverwenden und dadurch die Erstellung einer Software ganz von Beginn an überflüssig machen. Das Prinzip der Vererbung ermöglicht es einem Softwareentwickler, Klassen (und die Objekte, die später von ihnen erzeugt werden) als miteinander in einer Beziehung stehend zu deklarieren. Insbesondere können Klassen als Unterklassen anderer Basisklassen festgelegt werden. Eine Unterklasse "erbt" alle öffentlichen Funktionen ihrer Basisklassen und kann auf diese so zugreifen, als ob diese Funktionen in der Unterklasse selbst enthalten wären. Alternativ dazu kann eine Unterklasse einige oder alle ihrer geerbten Funktionen überschreiben oder einige oder alle ihrer geerbten Funktionen modifizieren, indem sie einfach eine neue Funktion mit derselben Form definiert (das Überschreiben oder Modifizieren ändert die Funktion in der Basisklasse nicht, sondern modifiziert bloß die Verwendung der Funktion in der Unterklasse). Die Erzeugung einer neuen Unterklasse, die einen Teil der Funktionalität (bei selektiver Modifizierung) einer anderen Klasse besitzt, ermöglicht es Softwareentwicklern, auf einfache Weise bestehenden Code maßzuschneidern, um bestimmte Bedürfnisse zu erfüllen.
• Obwohl das objektorientierte Programmieren wesentliche Verbesserungen gegenüber anderen Programmierkonzepten bietet, erfordert die Programmentwicklung dennoch einen großen Zeit- und Arbeitsaufwand, besonders dann, wenn keine fertigen Softwareprogramme vorhanden sind, die modifiziert werden können. Daher war es bis jetzt Stand der Technik, einem Programmentwickler eine Reihe vordefinierter, miteinander verknüpfter Klassen zur Verfügung zu stellen, die eine Gruppe von Objekten erzeugen, sowie verschiedene zusätzliche Routinen, die alle auf die Ausführung allgemein auftretender Aufgaben in einer bestimmten Umgebung ausgerichtet sind. Solche vordefinierten Klassen und Bibliotheken werden typischerweise als "Rahmenwerke" bezeichnet und bieten eine vorfabrizierte Struktur für eine Arbeitsanwendung.
• So könnte zum Beispiel ein Rahmenwerk für eine Benutzerschnittstelle eine Gruppe von vordefinierten Grafikschnittstellenobjekten bieten, die Fenster, Rollbalken, Menüs usw. erzeugen und die Unterstützung und das "Standard"-Verhalten für diese Grafikschnittstellenobjekte bieten. Da Rahmenwerke auf objektorientierten Techniken basieren, können die vordefinierten Klassen als Basisklassen verwendet werden, und das eingebaute Standardverhalten kann von Unterklassen, die vom Entwickler definiert werden, geerbt und entweder modifiziert oder überschrieben werden, damit Entwickler das Rahmenwerk erweitern und maßgeschnei derte Lösungen in einem bestimmten Fachbereich erstellen können. Dieser objektorientierte Ansatz bietet gegenüber dem herkömmlichen Programmieren große Vorteile, da der Programmierer das Originalprogramm nicht ändert, sondern vielmehr die Fähigkeiten des Originalproqramms erweitert. Darüber hinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine architekturbezogene Führung und Modellierung bietet, und gleichzeitig die Entwickler befreit, damit diese spezifische Maßnahmen im Hinblick auf den Problembereich ergreifen können.
• Es gibt viele verschiedene Arten von Rahmenwerken, die zur Verfügung stehen, welche von der Ebene des damit zusammenhängenden Systems und der Art des zu lösenden Problems abhängen. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken hoher Ebene, die bei der Entwicklung einer Anwenderschnittstelle helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwareservices, wie zum Beispiel Kommunikation, Drucken, Dateiablagesystemunterstützung, Grafik usw. bieten. Kommerzielle Beispiele für Anwendungsrahmenwerke sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NeXT), und Smalltalk-80 MVC (ParcPlace).
• Wenngleich der Ansatz der Rahmenwerke alle Prinzipien der Einkapselung, der Polymorphie und der Vererbung auf die Objektschicht anwendet und eine wesentliche Verbesserung gegenüber anderen Programmiertechniken darstellt, ergeben sich bei diesem Ansatz doch auch Schwierigkeiten. Anwendungsrahmenwerke bestehen desweiteren im allgemeinen aus einer oder mehreren "Schichten" an der Spitze eines monolithischen Betriebssystems, und selbst angesichts der Flexibilität der Objektschicht ist es oft noch notwendig, mittels mühevoller Prozeduraufrufe direkt mit dem darunterliegenden Betriebssystem zu interagieren.
• In derselben Weise, wie ein Anwendungsrahmenwerk dem Entwickler eine vorfabrizierte Funktionalität für einen Anwendungs-Thread bietet, kann ein Systemrahmenwerk, wie zum Beispiel jenes, welches in einer bevorzugten Ausführungsform enthalten ist, eine vorfabrizierte Funktionalität für Systemebenenservices bieten, die von den Entwicklern modifiziert oder überschrieben werden können, um maßgeschneiderte Lösungen zu erstellen, wodurch die mühevollen Prozeduraufrufe vermieden werden, die bei Anwendungsrahmenwerkprogrammen des Standes der Technik notwendig sind. Betrachten wir zum Beispiel ein Anzeigenrahmenwerk, das die Grundlage für das Erstellen, Löschen und Manipulieren von Fenstern zur Verfügung stellen könnte, um Informationen anzuzeigen, die von einem Anwendungs-Thread erzeugt wurden. Ein Anwendungssoftwareentwickler, der diese Fähigkeiten benötigt, würde normalerweise spezifische Routinen schreiben müssen, um diese Fähigkeiten bereitzustellen. Um dies mit einem Rahmenwerk zu tun, muß der Entwickler nur die Merkmale und das Verhalten der fertigen Anzeige zur Verfügung stellen, während das Rahmenwerk die eigentlichen Routinen liefert, welche die Aufgaben ausführen.
• Eine bevorzugte Ausführungsform geht vom Konzept der Rahmenwerke aus und wendet dieses im gesamten System einschließlich des Anwendungs- und Betriebssystems an. Für den kommerziellen oder firmeninternen Entwickler, den Systemintegrator oder OEM bedeutet dies, daß all die Vorteile, die für ein Rahmenwerk wie zum Beispiel MacApp dargestellt wurden, nicht nur auf die Anwendungsebene für solche Dinge wie Text und Anwenderschnittstellen übertragen werden können, sondern auch auf die Systemebene, für Dienstleistungen wie zum Beispiel Drucken, Grafiken, Multimedia, Dateisysteme, E/A, Testdurchführung, usw.
• Fig. 4 zeigt eine schematische Übersicht eines Computersystems, welches das objektorientierte Ansichtsrahmenwerk der vorliegenden Erfindung verwendet. Das Computersystem ist im allgemeinen als Box 400 dargestellt, und es sind eine Anwendung 416 mit mehreren Ausführungs-Threads (von denen die Anwendungs-Threads 401 und 402 dargestellt sind) und ein Betriebssystem 404 vorhanden, um den Funktionsablauf des Computers zu steuern und zu koordinieren. Um Fig. 4 zu vereinfachen, ist die Interaktion der Anwendung 416 mit dem Betriebssystem 404 auf die Interaktionen beschränkt, die sich mit den Bildschirmdarstellungen beschäftigen. Wie in der Figur dargestellt, besitzen beide Anwendungs-Threads 401 und 402 eine Schnittstelle zum Ansichtssystemabschnitt 405 des Anwendungsprogramms, wie dies durch die Pfeile 403 und 406 dargestellt ist. Das Ansichtssystem 405 sendet wiederum Informationen zum Bildschirmzwischenspeicher 410 und zum Betriebssystem 404, wie dies schematisch durch den Pfeil 407 und 420 dargestellt ist.
• Gemäß der Erfindung und wie in Fig. 4 dargestellt senden die Anwendungs-Threads 401 und 402 jedoch auch direkt Informationen zum Bildschirmzwischenspeicher 410, wie dies durch den Pfeil 407 veranschaulicht wird. Wie im folgenden noch genauer erklärt wird, liefern die Anwendungs-Threads 401 und 402 Anzeigeinformationen direkt zum Bildschirmzwischenspeicher 410 und holen gespeicherte Informationen vom Ansichtssystem 405, wenn ein Zeichnen erforderlich ist. Insbesondere berechnet das Ansichtssystem 405 den sichtbaren Bereich einer jeden Ansicht neu, wenn eine Ansicht geändert wird, und speichert ihn. Dieser gespeicherte sichtbare Bereich wird vom jeweiligen Anwendungs-Thread geholt und als Abschneideregion verwendet, in welche die Anwendung die Anzeigeinformationen zeichnet. Ein Neumalen oder Zeichnen der Ansicht wird von den Anwendungs- Threads gleichzeitig ausgeführt, um die Geschwindigkeit des Neumalens am Bildschirm zu erhöhen.
• Die Anwendungsanzeigen werden vom Anzeigenbildschirm getrennt gehalten, weil das Ansichtssystem 405 die sichtbaren Ansichtsbereiche neu berechnet, so daß sich keine der Bereiche überlappen. Wenn somit jeder Anwendungs-Thread, wie zum Beispiel der Anwendungs-Thread 401 oder der Anwendungs-Thread 402, nur in den sichtbaren Bereich zeichnet, der ihm vom Ansichtssystem 405 zur Verfügung gestellt wird, gibt es keine Überlappungen in den Anzeigen, die vom Bildschirmzwischenspeicher erzeugt werden. Nachdem die Anzeigeinformationen in den Bildschirmzwischenspeicher 410 gezeichnet wurden, werden sie, wie dies durch den Pfeil 412 dargestellt ist, zu einem Anzeigenadapter 414 gesendet, der wiederum über ein Kabel oder einen Bus 422 mit dem Anzeigemonitor 424 verbunden ist.
• Die Interaktion eines Anwendungs-Threads mit dem Ansichtssystem ist detaillierter im schematischen Diagramm der Fig. 5 dargestellt. Wie zuvor erwähnt, handelt es sich bei dem Ansichtssystem (dargestellt als Box 510 in Fig. 5) um ein objektorientiertes Programm. Demgemäß erzeugt ein Anwendungs-Thread 508 eine Schnittstelle zum Ansichtssystem, indem er "Objekte" erzeugt und manipuliert. Insbesondere erzeugt jeder Anwendungs-Thread ein Ansichtshierarchieobjekt, wie zum Beispiel das Ansichtshierarchieobjekt 512, um mit dem Ansichtssystem 510 zu kommunizieren. Der Anwendungs-Thread 508 kommuniziert daraufhin mit dem Ansichtshierarchieobjekt 512, indem er ein Ansichtsobjekt 506 erzeugt und dieses, wie schematisch durch den Pfeil 502 dargestellt, in die Hierarchie einbaut. Das Ansichtssystem selbst ist eine Sammlung von Objekten, die erzeugt wird, wenn das Anwendungsprogramm gestartet wird. Das Ansichtssystem 510 erzeugt über einen Datenstrom 504 eine Schnittstelle zum Betriebssystem 500, um Fensteroperationen im Auftrag des Anwendungsprogramms und des Ansichtssystems 510 auszuführen.
• Wie im folgenden noch genauer beschrieben wird, umfaßt jedes Ansichtsobjekt 506 einen kleinen Datenspeicherbereich oder "Cache"-Bereich, der als Zeichenzustand 514 bezeichnet und dazu verwendet wird, den zugeordneten sichtbaren Ansichtsbereich und anderen zeichnungsbezogenen Zustand (Koordinatensystem, usw.) zu speichern. Wenn der Anwendungs- Thread die Informationen in einer der ihm zugeordneten Ansichten neu zeichnen möchte, überprüft das Ansichtsobjekt zuerst den Cache-Status. Wenn sich die im Cache gespeicher ten Informationen nicht geändert haben oder ungültig geworden sind, werden diese Informationen zum Neuzeichnen des Fensters verwendet. Die Verwendung des Cache-Bereiches verkürzt die Zeit, die zur Vervollständigung eines Neuzeichnen-Vorgangs notwendig ist.
• Da viele Ansichtsobjekte gleichzeitig erzeugt werden können, um zur selben Zeit viele Ansichten innerhalb eines Fensters darzustellen, kommuniziert jedes Ansichtsobjekt 506 mit dem Ansichtssystem 510 mittels multitask-sicherer Verfahrensaufrufe 502. Das Ansichtssystem kommuniziert mit dem Betriebssystem über den Datenstrom 504, indem es "Strom"-Objekte erzeugt, die Softwarebefehle enthalten, welche zur Übertragung von einem Objekt zum anderen notwendig sind. Wenn zum Beispiel das Betriebssystem 500 Informationen zum Ansichtssystemobjekt 513 übertragen möchte, erzeugt das Betriebssystem 500 ein Stromobjekt, das Daten in das Ansichtssystemobjekt 510 "strömt". Wenn das Ansichtssystemobjekt 510 Informationen zurück zum Betriebssystem 500 übertragen möchte, erzeugt das Ansichtssystemobjekt 510 auf ähnliche Weise ein Stromobjekt, welches die Daten in das Fensterobjekt 500 "strömt". Solche Stromobjekte sind herkömmlicher Art und werden hier nicht im Detail beschrieben. Die Stromobjekte, die Daten vom Betriebssystem 500 zum Ansichtssystemobjekt 510 tragen, und die Stromobjekte, die Informationen vom Ansichtssystemobjekt 510 zum Betriebssystem 500 tragen, sind gemeinsam als Pfeil 504 dargestellt.
• Wie in Fig. 5 dargestellt, besteht das Ansichtssystemobjekt 510 aus vier Hauptteilen: dem Ansichtshierarchierahmenwerk 512, dem einen oder mehre: en Ansichtsobjekt(en) (und ihren zugeordneten Befehlsobjekten), die in der Hierarchie 506 installiert sind, dem Zeichnungszustand, der für jede Ansicht in der Hierarchie 514 im Cache zwischengespeichert ist, und dem Rahmenwerk, um die Hintergrundaktualisierung der "ungültigen" Bereiche innerhalb der in der Hierarchie 516 installierten Ansichten zu unterstützen. Das Hintergrundaktualisierungsrahmenwerk 516 umfaßt einen unabhängigen Task, der vom Ansichtssystem 510 gestartet wird, wenn das Ansichtssystem 510 erzeugt wird. Wie im folgenden im Detail erklärt wird, ist das Hintergrundaktualisierungsrahmenwerk für die Auffrischung der Abschnitte der Ansichten 506 in der Ansichtshierarchie 51.2 verantwortlich, die am Datenanzeigebildschirm sichtbar sind und durch Ansichtshierarchieänderungen, lokale Ansichtsänderungen oder Fenstermanipulationen ungültig wurden. Zu diesem Zweck sammelt es Bereiche, die aktualisiert werden müssen, berechnet den sichtbaren Bereich einer Ansicht neu, der sich mit dem "unsichtbaren" Bereich überschneidet, und weist die betroffene Ansicht an, nur jenen Abschnitt von sich selbst aufzufrischen, der ungültig ist.
• Der Zeichnungszustands-Cache 514 besteht aus einer Anzahl unterschiedlicher Objekte, die gemeinsam Informationen speichern, die mit den Zeichnungsattributen und der Umgebung für die zugeordnete Ansicht im Zusammenhang stehen. Der Zeichnungszustands-Cache wird vom Ansichtssystem im Auftrag der einzelnen Ansichten erzeugt und vom Ansichtssystem einschließlich eines "Zeitstempels" gewartet, der die Zeit der letzten Modifikation angibt.
• Wie zuvor erwähnt, ist das Betriebssystem gemäß einer bevorzugten Ausführungsform in der Lage, mehrere Threads gleichzeitig auszuführen, und wann immer zwei oder mehrere Threads gleichzeitig operieren, besteht die Möglichkeit einer gegenseitigen Interaktion. Zu einer solchen gegenseitigen Interaktion kann es kommen, wenn zwei oder mehrere Threads versuchen, auf gleichzeitig freigegebene Ressourcen zuzugreifen, wie zum Beispiel die Ansichtshierarchie. Demgemäß sind Mehrfachzugriffskontrollen notwendig, um solche Interaktionen zu verwalten und unerwünschte Störungen zu verhindern. Eine veranschaulichende Mehrfachzugriffskontrolltechnik, die als Überwachungsprogramm bekannt ist, wird in einer Ausführungsform verwendet. Überwachungsprogramme sind gut bekannte Einrichtungen, die dazu verwen det werden, gleichzeitige Zugriffsversuche auf eine Ressource zu "serialisieren" und eine objektorientierte Schnittstelle zu schaffen. Insbesondere muß, bevor ein Thread auf eine Ressource zugreifen kann, die von einem Überwachungsprogramm kontrolliert wird, dieser das Überwachungsprogramm "in Besitz nehmen". Wenn der Thread mit der Ressource fertig ist, gibt er das Überwachungsprogramm frei, damit es von einem anderen Thread in Besitz genommen werden kann. Jedes Überwachungsprogramm besitzt eine Anforderungswarteschlange, die ihm zugeordnet ist, so daß Anforderungen zur Besitznahme des Überwachungsprogramms, denen nicht entsprochen werden kann (weil das Überwachungsprogramm gerade von einem anderen Thread in Besitz genommen ist), in der Warteschlange gehalten werden (was als "Sperrung" bezeichnet wird). Überwachungsprogramme stellen auch einen Mechanismus zur Verfügung, um eine Inbesitznahme solange zu verhindern, bis eine bestimmte "Bedingung" erfüllt ist.
• Im vorliegenden System werden Überwachungsprogramme dazu verwendet, mehrere unterschiedliche freigegebene Ressourcen zu schützen. Insbesondere wird ein Ansichtssystem- Überwachungsprogramm dazu verwendet, zu verhindern, daß die Anwendungs-Threads gleichzeitig mit dem Ansichtssystem interagieren und Daten verfälschen. Vor dem Zugriff auf die im Cache zwischengespeicherten Zeichnungsdaten muß jeder Anwendungs-Thread das Ansichtssystem-Überwachungsprogramm in Besitz nehmen. Das im vorliegenden System verwendete Überwachungsprogramm ermöglicht es einzelnen Threads, ein gegebenes Überwachungsprogramm "erneut in Besitz zu nehmen", um zu verhindern, daß sich ein 'Thread selbst sperrt.
• Fig. 6 zeigt eine beispielhafte Bildschirmanzeige, die von einem typischen "Fensterumgebungs"-Programm erzeugt wurde. Ein Fenster 600 ist ein von Grenzen umschlossener Bereich, der auf herkömmliche Weise verschoben und in seiner Größe verändert werden kann. Das Fenster 600 umfaßt normalerweise eine Titelleiste 606 und eine Menüleiste 604, bei denen es sich jeweils um eine Ansicht handelt, und die selbst andere Ansichten enthalten können. Die Menüleiste 604, bei der es sich auch um eine Ansicht handelt, erlaubt den Zugriff auf eine Anzahl von Pull-Down-Menüs (nicht dargestellt), die auf eine gut bekannte Weise betätigt werden und dem Benutzer den Zugriff auf verschiedene Datei- Bearbeitungs- und andere Befehle ermöglicht.
• Der nach Ausschluß der Titelleiste 606, der Menüleiste 604 und der Grenzen innerhalb des Fensters verbleibende Bereich wird als "Inhaltsansicht" bezeichnet und stellt die Hauptfläche dar, in welche ein Anwerdungs-Thread, wie zum Beispiel ein Zeichenprogramm, zeichnen oder malen kann. Eine Inhaltsansicht kann zusätzliche Ansichten umfassen, die als "Kind"-Ansichten bezeichnet werden, welche mit dem einen oder den mehreren Anwendungs-Threads in Verbindung stehen. In diesem Fall wird die enthaltende Ansicht als "Eltern"-Ansicht oder "Container"-Ansicht in bezug auf das bzw. die Kind-Ansicht(en) bezeichnet. Jede Kind-Ansicht kann selbst auch eine oder mehrere mit ihr in Verbindung stehende Kind-Ansichten besitzen, für welche sie eine Eltern-Ansicht ist, und so weiter, wodurch eine Ansichtshierarchie erzeugt wird.
• Viele Anwendungs-Threads unterteilen weiter die Inhaltsansicht in eine Anzahl an Kind-Ansichten, die unabhängig voneinander kontrolliert werden. Diese umfassen typischerweise eine Dokumentansicht 622, eine "Symbolleisten-" oder "Paletten"-Ansicht 616 und in manchen Fällen eine Statuszeilenansicht (nicht dargestellt). Die Dokumentansicht 622 kann mit horizontalen und vertikalen Rollbalkenansichten 618 und 614 ausgestattet sein, mit denen Objekte in der Dokumentenansicht am Bildschirm verschoben werden können. Die Dokumentansicht 622 kann weiters in Kind- Ansichten 602, 610 und 620 unterteilt werden, die einander auch überlappen können (und nicht rechteckig sein müssen). Für gewöhnlich ist jeweils nur eine der Kind-Ansichten 602, 610 und 620 aktiv, und nur eine Ansicht besitzt den "Eingabefokus". Nur jene Ansicht, die den Eingabefokus besitzt, reagiert auf Eingabemaßnahmen und Befehle von den Eingabegeräten, wie zum Beispiel der Maus und der Tastatur.
• Die Symbolleisten-/Palettenansicht 616 enthält für gewöhnlich eine Anzahl an Symbolbildern, wie zum Beispiel die Symbole 608 und 612, die auf komfortable Weise dazu verwendet werden können, bestimmte oft verwendete Programme oder Unterroutinen zu starten. Zum Beispiel kann das Symbol 608 ausgewählt werden, um eine Zeichenroutine zu starten, die eine Box am Bildschirm zeichnet, wohingegen das Symbol 612 ein Rechtschreibprüfprogramm starten könnte. Die Operation solcher Symbolleisten und Paletten ist im allgemeinen gut bekannt und wird deshalb hierin nicht näher beschrieben.
• Die angezeigten Steuerelemente werden im allgemeinen mittels einer Maus oder eines anderen Eingabegerätes ausgewählt. Die Maus steuert einen Cursor, der vom Betriebssystem auf den Bildschirm gezeichnet wird. Wenn der Cursor über das auszuwählende Grafikbild gesetzt wird, wird eine Taste an der Maus aktiviert, woraufhin das Ansichtssystem reagiert.
• Wenngleich die oben diskutierten Steuerelemente im allgemeinen vom Anwendungs-Thread nicht verschoben oder in ihrer Größe verändert werden können, stehen die Inhaltsansicht und die Kind-Ansichten für gewöhnlich vollständig unter der Kontrolle des Anwendungs-Threads. Wenn ein Anwendungs-Thread mehrere Ansichten oder mehrere Anwendungs- Threads besitzt, die gleichzeitig laufen und Informationsansichten darstellen, verursachen Änderungen in der Größe oder der Position einer Ansicht eine Änderung der angezeigten oder sichtbaren Bereiche der Ansichten, die "unter" der geänderten Ansicht liegen. Fig. 7A und 7B zeigen, wie eine Manipulation einer Ansicht, die einer Anwendung zugeordnet ist, die sichtbaren Bereiche anderer Ansichten ändern kann, die derselben Anwendung zugeordnet sind und innerhalb desselben Fensters liegen.
• Insbesondere zeigt Fig. 7A drei Ansichten, die sich innerhalb eines Fensters befinden. Die Ansichten überlappen sich - Ansicht 700 liegt im Hintergrund, Ansicht 702 liegt vor der Ansicht 700, und Ansicht 704 liegt vor der Ansicht 702. Wie in Fig. 7A gezeigt, verdeckt die Ansicht 704 Abschnitte der Ansichten 702 und 700. Da die einzelnen Ansichten 700, 702 und 704 jeweils unabhängig voneinander verschoben und in ihrer Größe verändert werden können, ist es möglich, daß Bereiche in den überlappenden Ansichten freigelegt oder bedeckt werden können und sich dadurch das Erscheinungsbild dieser Ansichten ändert, wenn die vordersten Ansichten 702 oder 704 verschoben oder in ihrer Größe verändert werden. Aufgrund der überlappenden Erscheinung der Ansichten hat eine Änderung an einer ausgewählten Ansicht jedoch nur Auswirkungen auf die Ansicht hinter der ausgewählten Ansicht. Zum Beispiel wirkt sich eine Änderung an der Ansicht 704 auf die Ansichten 702 und 700 aus, aber eine Änderung an der Ansicht 700 kann sich nicht auf die Ansichten 702 oder 704 auswirken, da sich diese letzteren Ansichten überlappen und Abschnitte der Ansicht 700 verdecken.
• Fig. 7B zeigt die Auswirkungen einer Größenveränderung an der vorderen Ansicht 704 in Fig. 7A. Insbesondere zeigt Fig. 7B drei Ansichten 712, 714 und 706, die den Ansichten 704, 702 bzw. 700 in Fig. 7A entsprechen. In Fig. 7B wurde die Ansicht 712 jedoch in ihrer Größe verändert und insbesondere im Vergleich zur ursprünglichen Größe der Ansicht 704 verkleinert. Durch die Verringerung der Größe der Ansicht 712 wird eine Fläche (dargestellt als schattierter Bereich) der Ansicht 710 freigelegt, der zuvor noch vollkommen von der Ansicht 712 verdeckt war. Auf ähnliche Weise wird auch der schattierte Bereich 708 der Ansicht 706 freigelegt. Gemäß der normalen Ansichtssystemoperation werden nur sichtbare Abschnitte von Ansichten gemalt. Demgemäß müssen die Bereiche 708 und 710 neu gezeichnet oder neu gemalt werden, da sie nun sichtbare Be reiche geworden sind. Diese Bereiche, die neu gezeichnet werden müssen, werden als "ungültige" Bereiche" oder "Aktualisierungsbereiche" bezeichnet. Dieses Neuzeichnen erfolgt, wie zuvor beschrieben, durch eine Koordination zwischen dem Hintergrundaktualisierungsrahmenwerk des Ansichtssystems und dem Anwendungs-Thread, der den ungültigen Bereich "besitzt".
• Insbesondere berechnet das Ansichtssystem den neuen sichtbaren Bereich einer jeden geänderten Ansicht und aller Ansichten, die hinter der geänderten Ansicht liegen. Das Ansichtssystem sendet daraufhin eine "Aktualisierungsanforderung" an jede Ansicht, die mit einem geänderten Bereich in Verbindung steht, um der Ansicht anzuzeigen, daß ein Teil ihres sichtbaren Bereiches neu gezeichnet werden muß. Jede Ansicht aktualisiert wiederum den sichtbaren Bereich, indem sie direkt in den Bildschirmzwischenspeicher schreibt.
• Der Prozeß des Neuzeichnens eines neuen sichtbaren Bereiches ist im Detail in dem in Fig. 8 gezeigten Flußdiagramm dargestellt. Insbesondere beginnt die Neumalroutine bei Schritt 800 und geht zu Schritt 802 weiter, wo das Hintergrundaktualisierungsrahmenwerk eine Aktualisierungsanforderung vom Ansichtssystem empfängt. Eine Aktualisierungsanforderung kann erzeugt werden, wenn das Ansichtssystem eine Ansicht in ihrer Größe verändert, wie dies in Fig. 7A und 7B dargestellt ist, oder als Antwort auf eine soeben freigelegte Fensterfläche. Bei der Reaktion nimmt das Aktualisierungsrahmenwerk das Ansichtssystem-Überwachungsprogramm im Funktionsblock 804 in Besitz, holt alle anstehenden Aktualisierungen und vereint diese zu einem einzigen Aktualisierungsobjekt, wie dies in Schritt 806 dargestellt ist. Danach wird ein Zeitstempel überprüft, um zu erkennen, ob der Anzeigezwischenspeicher des Ansichtssystems veraltet ist; Schritt 808. Wenn der Zwischenspeicher aktuell ist, wird er wie in Schritt 810 gezeigt zur Anzeige kopiert. Wenn der Zeitstempel veraltet ist, muß der Anzei ge-Cache des Ansichtssystems aufgefrischt werden. Bei Schritt 812 wird eine Liste der Ansichten erzeugt, die den Aktualisierungsbereich überlappen. Zu diesem Zeitpunkt wird das Ansichtssystem-Überwachungsprogramm freigegeben; 814. Das Hintergrundaktualisierungsrahmenwerk iteriert danach durch jede Ansicht in der Aktualisierungsliste 816 und legt fest, ob die Ansicht einen zugeordneten Anwendungs-Thread für die Verarbeitung der Aktualisierungen besitzt 818.
• Wenn die Ansicht selbst keinen eigenen Hintergrundaktualisierungs-Thread besitzt, weist der Ansichtssystem- Hintergrundaktualisierungsmechanismus die Ansicht an, den ungültigen Bereich in den Ansichtssystem-Zwischenspeicher 820 neu zu zeichnen. Wenn die Ansicht jedoch ihren eigenen Aktualisierungs-Thread besitzt, wird der ungültige Bereich innerhalb dieser Ansicht dem Aktualisierungs-Thread 822 der Ansicht übergeben (der dafür sorgt, daß der Zwischenspeicher aktualisiert und zu einem späteren Zeitpunkt zur Anzeige kopiert wird). Zu diesem Zeitpunkt wird der aktuelle Ansichtssystem-Anzeigenzwischenspeicher zum Anzeigengerätezwischenspeicher 824 kopiert, der Abschnitt der mit dieser Ansicht im Zusammenhang stehenden Aktualisierung wird vom Hintergrundaktualisierungsrahmenwerk 826 als abgeschlossen gekennzeichnet, und der Thread geht zurück, um auf weitere Aktualisierungen 828 zu warten.
• Wie zuvor erwähnt, kann ein Ansichtsobjekt mit dem Ansichtshierarchieobjekt interagieren, um verschiedene Ansichtshierarchieverwaltungsfunktionen zu ermöglichen, wie zum Beispiel das Erstellen einer neuen Ansicht und das Einfügen derselben in die Hierarchie. Eine beispielhafte Routine, die vom Anwendungsentwickler verwendet wird, um eine neue Ansicht zu erzeugen, ist im Detail im Flußdiagramm von Fig. 9 dargestellt. Die Routine beginnt bei Schritt 900 und geht zu Schritt 902 weiter, wo eine neue Kind-Ansicht konstruiert wird.
• Nachdem die Ansicht bei Schritt; 902 konstruiert und initialisiert wurde, geht die Routine zu Schritt 904 wei ter, wo ein "Modifizierer"-Objekt erzeugt wird, um Modifikationen an der Ansichtshierarchie zu unterstützen und zu ermöglichen. Bei Schritt 908 wird das "Add"-Verfahren (Einfüge-Verfahren) am Modifiziererobjekt aufgerufen, und die neu konstruierte Kind-Ansicht wird in die Ansichtshierarchie eingefügt. Das Modifiziererobjekt kann dann wie in Schritt 910 weggeworfen werden. Die Routine endet bei Schritt 914.
• Wie zuvor erwähnt, stellt das Ansichtssystem ein Rahmenwerk zur Verfügung, das die Eigenfähigkeiten der C++- Sprache erweitert, um die Konstruktion und Initialisierung von C++-Objekten zu unterstützen. Die bei der Verwendung der vom Ansichtssystem zur Verfügung gestellten Initialisierungs- und Finalisierungsunterstützung ausgeführten Schritte sind im Detail im Flußdiagramm von Fig. 10 dargestellt. Die Routine beginnt bei Schritt 1000, und das fragliche Ansichtsobjekt wird bei Schritt 1002 konstruiert (wobei die standardmäßige C++ "Konstruktor"-Einrichtung verwendet wird). Nach der Konstruktion des Objektes wird das "Initialisierungs"-Verfahren des Ansichtsobjektes automatisch vom Laufzeitsystem aufgerufen, wie dies in Schritt 1005 dargestellt ist. Eine Beschränkung der C++ -Konstruktionsmerkmale macht es unmöglich, virtuelle Verfahrensaufrufe aus dem Konstruktor eines Objektes heraus zu machen. Das "Initialisierungs"-Verfahren stellt einen Mechanismus zur Verfügung, um virtuelle Verfahren eines Objektes aufzurufen, nachdem die Konstruktion abgeschlossen ist, aber bevor irgendwelche anderen Verfahren am Objekt aufgerufen werden. Dies ist besonders für Unterklassen nützlich, die Basisklassenverhalten zur Zeit der Konstruktion oder Initialisierung modifizieren müssen. Wenn der Benutzer die laufende Anwendung beendet oder irgend ein anderes Ereignis dazu führt, daß die Ansichtshierarchie (oder auch nur eine einzelne Ansicht) zerstört werden muß, wird ein ähnlicher Mechanismus verwendet, um sicherzustellen, daß ein "Finalisierungs"-Verfahren nach dem letzten Verfahrensaufruf, aber unmittelbar vor der Ausführung des Destruktors des Objekts, vom Laufzeitsystem aufgerufen wird. Dieser Mechanismus ermöglicht es, Verhalten in der Basisklasse bezüglich der Finalisierung oder Zerstörung eines Objektes zu übergehen. Schritt 1006 zeigt die Entfernung der Ansicht aus der Hierarchie, den Aufruf des "Finalisierungs"-Verfahrens der Ansicht durch das Laufzeitsystem, Schritt 1007, und den Aufruf des Destruktors der Ansicht.; Schritt 1008. Die Operation endet bei Schritt 1010.
• Fig. 11 ist ein Flußdiagramm, das eine veranschaulichende Routine darstellt, die vom Ansichtssystem verwendet wird, um einzelne Ansichten mit eventuellen Änderungen im Ansichtssystem zu synchronisieren, die diese beeinträchtigen könnten. Die Routine beginnt bei Schritt 1100. Das Ansichtsüberwachungsprogramm wird bei Schritt 1102 in Besitz genommen. Diese Überwachungsprogrammsperrung verhindert für die Dauer der Routine weitere Änderungen im Ansichtssystem. Ein Zeitstempel innerhalb des Ansichtsobjekts wird in Schritt 1104 mit der "Zeituhr" des Ansichtssystems verglichen, um zu bestimmen, ob der im Cache zwischengespeicherte Ansichtszustand nun veraltet ist; Schritt 1106. Wenn der Cache aktuell ist, wird er dem Aufruf er in Schritt 1108 zur Verfügung gestellt. Das Ansichtsüberwachungsprogramm wird bei 1122 freigegeben und die Routine abgeschlossen. Wenn der Zeitstempel bei Schritt 1106 veraltet ist, muß der Ansichtszustand neu berechnet werden. Bei Schritt 1110 wird eine Kopie des Zustandes der Eltern-Ansicht genommen (die eine ähnliche Routine durchlaufen wird wie in Fig. 11 dargestellt, um ihren Zustand einer anfordernden Kind- Ansicht zur Verfügung zu stellen). Das Ansichtsobjekt fügt dann etwaige lokale Zustandsinformationen ein, wie zum Beispiel den Abstand, um den die Ansicht von ihrer Eltern- Ansicht verschoben wird, und den Unterschied zwischen dem Bereich, der von der Eltern-Ansicht "besessen" wird, und sich selbst; Schritt 1112. Nachdem der aktuelle Zustand berechnet wurde, wird er (Schritt 1 : 14) gemeinsam mit dem aktuellen Zeitstempel (Schritt 1116) erneut im Cache zwischengespeichert. Das Ansichtsüberwachungsprogramm wird bei 1122 freigegeben und die Routine bei Schritt 1124 abgeschlossen. Das schematische Diagramm in Fig. 12 zeigt drei unterschiedliche Ansichten, welche die Vielfältigkeit der Ansichtsbereichsunterstützung durch das Ansichtssystemrahmenwerk zeigt. Das einschließende Fensterobjekt 1200 ähnelt jenem, das in Fig. 6 beschrieben wurde. Die Inhaltsansicht 1208 des Anwendungsentwicklers ist im Fenster 1200 enthalten. Die Ansicht 1206 ist eine Kind-Ansicht der Inhaltsansicht, die nicht rechteckig ist, wenngleich sie eine mehr oder weniger herkömmliche Form besitzt. Die Ansicht 1202 ist eine nicht geradlinige Ansicht, bei der es sich um ein geschlossenes Vieleck handelt, und sie ist auch eine Kind- Ansicht der Inhaltsansicht 1208. Die dritte Kind-Ansicht 1204 im Inhaltsfenster 1208 ist eine nicht angrenzende Ansicht, die zwei getrennte, nicht geradlinige Abschnitte besitzt. In diesem Beispiel überlappen sich die Kind- Ansichten nicht, und eine Reihung von vorne nach hinten ist hier nicht ausdrücklich vorhanden. Dies bedeutet nicht, daß eine Reihung (und damit eine Begrenzung) nicht möglich ist, sondern nur, daß dies in dieser Figur nicht gezeigt wird.
• Das schematische Diagramm in Fig. 13 zeigt zwei Möglichkeiten für Koordinatenräume innerhalb einer gegebenen Ansicht. Die Koordinatenebenen in einer gegebenen Ansicht sind für gewöhnlich unsichtbar, wurden aber in dieser Figur zwecks leichterer Erklärung sichtbar gemacht. Das Fenster 1200 ähnelt jenem, das in Fig. 6 beschrieben wird. Die Inhaltsansicht 1202 des Entwicklers ist im Fenster 1200 enthalten. Zwei Kind-Ansichten der Inhaltsansicht sind in dieser Figur dargestellt, nämlich Ansicht 1210 und 1206. Die Ansicht 1206 ist eine Ansicht, bei der das Standard- Koordinatensystem vom Ansichtsrahmenwerk zur Verfügung gestellt wird. Sie besteht aus einer "X"-Achse 1204 und einer "Y"-Achse 1208, die sich in die positive und negative Unendlichkeit erstrecken. Standardmäßig befindet sich der "Ursprung" in der oberen linken Ecke des angrenzenden Rechtecks der Ansicht. Die positive "X"-Richtung erstreckt sich vom Ursprung weg nach rechts, und die positive "Y"- Richtung erstreckt sich vom Ursprung weg nach unten. In der Ansicht 1206 wurde der Ursprung 12 : 12 leicht verschoben, aber ansonsten wurden keine anderen Änderungen am Standard- Koordinatenraum vorgenommen. In der Ansicht 1210 steht ein polares Koordinatensystem in Betrieb. Der Ursprung 1216 der Ansicht befindet sich in der Mitte der Ansicht 1210. Wie im kartesischen Koordinatensystem in der Ansicht 1206 erstreckt sich auch das polare Koordinatensystem in der Ansicht 1210 in die Unendlichkeit, wie dies durch den Pfeil 1214 dargestellt ist. Beide dargestellten Koordinatensysteme sind standardmäßige, zweidimensionale Koordinatenebenen. Dreidimensionale (3D) Koordinatenräume sind auch möglich, werden aber vom Ansichtsrahmenwerk nicht ausdrücklich unterstützt. Um einen 3D-Koordinatenraum zu verwenden, müßte der Entwickler eine 3D-zu-2D-Zuordnung für die Verwendung durch das Ansichtsrahmenwerk schaffen. Im allgemeinen stellt dies kein Problem dar, weil das Grafiksystem implizit 3D-Objekte in einer 2D-Koordinatenebene unterstützt.
• Das schematische Diagramm in Fig. 14 zeigt den Ausrichtungs- und Anordnungsmechanismus, der vom Ansichtsrahmenwerk zur Verfügung gestellt wird. Das Fenster 1400 ähnelt jenem, das in Fig. 6 beschrieben wird. Die Inhaltsansicht 1410 des Entwicklers ist im Fenster 1400 enthalten. Die Ansichten 1410, 1412, 1414 und 1416 sind allesamt Kind- Ansichten der Inhaltsansicht. Diese Ansichten sind Objekte, die vom Ansichtsrahmenwerk zur Verfügung gestellt werden und ausdrücklich für die Anordnung anderer Ansichtsobjekte verwendet werden. Obwohl es nicht möglich ist, die Anordnungsansichten selbst zu sehen (sie besitzen keine Zeichenfähigkeiten), sind sie in der Ansichtshierarchie unmittelbar über den Ansichten eingebaut, für die sie Anordnungsattribute besitzen, und sie können auf die selbe Weise ver schachtelt werden wie andere Ansichtsobjekte. Die Ansicht 1402 ist eine Kind-Ansicht der Anordnungsansicht 1410. Die Ansicht 1404 ist eine Kind-Ansicht der Anordnungsansicht 1412. Die Ansicht 1406 ist eine Kind-Ansicht der Anordnungsansicht 1414. Die Ansicht 1408 ist eine Kind-Ansicht der Anordnungsansicht 1416. Die Ansichten 1410, 1412 und 1414 besitzen Attribute, durch welche sie waagerecht am Mittelpunkt ausgerichtet werden. Die Ansichten 1416 und 1410 werden ebenso senkrecht ausgerichtet, und zwar beide an der linken Seite.
• Fig. 15 ist ein Flußdiagramm einer veranschaulichenden Routine, die vom Ansichtssystem zur Anordnung der Ansichten verwendet wird, um die in Fig. 14 beschriebene Anordnung zu erzeugen. Die Routine beginnt bei Schritt 1500. Das Ansichtssystem fragt eine Anordnungsansicht bei Schritt 1502 nach ihren waagerechten und senkrechten Attributen ab. Bei Schritt 1506 bestimmt das Ansichtssystem, ob die Ansicht in ihrer Größe flexibel ist. Wenn sie flexibel ist, kann die Größe der Ansicht verändert werden, um ihre Anordnungswünsche zu berücksichtigen; Schritt 1508. Wenn die Ansicht in ihrer Größe nicht flexibel ist, wird ihre Größe nicht verändert. Nachdem die Größenveränderungen abgeschlossen sind, kann die Ansicht wünschen, etwas verschoben zu werden, um Leerräume zwischen Geschwister einzufügen; Schritt 1510 und 1512. Nachdem die Anordnung abgeschlossen ist, werden alle Anzeigebereiche, die geändert wurden, als solche markiert, die vom Ansichtssystem neu gezeichnet werden müssen, und eine Aktualisierungsanforderung wird an das Hintergrundaktualisierungsrahmenwerk geschickt. Die Routine wird bei Schritt 1516 abgeschlossen.
• Das schematische Diagramm in Fig. 16 zeigt eine einfache Matrixumwandlung, die innerhalb eines Ansichtsobjektes verwendet wird, um einen Effekt an einem anderen Ansichtsobjekt auszuführen. Das Fenster 1600 ähnelt während des Betriebes jenem, das in Fig. 6 beschrieben wird. Die Inhaltsansicht 1608 ist im Fenster 1600 enthalten. Die Ansicht 1602 ist eine rechtwinkelige Ansicht, die den Text "Hello, World" enthält. Der Ansichtseffekt 1604 ist eine "Vergrößerungsansicht", welche die Ansicht(en), die "unter" ihr liegen, um das eineinhalbfache (150%) vergrößert anzeigt. Dies erfolgt durch Verwendung des Matrixobjektes, das der Vergrößerungsansicht zugeordnet ist, und der Unterstützung durch das Ansichtssystem und das Grafiksystem, mehrere Matrixobjekte zu halten und zu verwenden. Die Ansicht 1604 könnte vom Benutzer über die Inhaltsansicht 1608 verschoben werden (durch Verwendung einer Matrixumwandlung sowie der Matrixskalierung), um andere Abschnitte der Inhaltsansicht zu "vergrößern".
• Das schematische Diagramm in Fig. 17 zeigt den Mechanismus, der vom Ansichtsrahmenwerk zur Verfügung gestellt wird, um getrennte Fenster in einer einzelnen Schicht zu "gruppieren", so daß sie sich relativ zu anderen Fenstern als eine einzige Gruppe "bewegen". Zum Beispiel bewegt der Anwender die Maus über ein Fenster 1702 und drückt die Maustaste, um dieses Fenster auszuwählen; das Fenster 1704 und das Fenster 1706 werden sofort gemeinsam mit dem Fenster 1702 in den Vordergrund der Anzeige gebracht. Wenn eines der drei Fenster 1702, 1704 oder 1706 ausgewählt wird, werden alle drei Fenster ausgewählt und in den Vordergrund der Anzeige gebracht.
• Fig. 18 ist ein Flußdiagramm einer beispielhaften Routine, die vom Ansichtssystem verwendet wird, um die Verwendung nicht-multitasksicherer Objekte durch ein Rahmenwerk zu ermöglichen, das Multitasking unterstützt, wie dies beim Ansichtssystemrahmenwerk der Fall ist. Dieser Mechanismus funktioniert ohne Modifizierungen an der Arbeitsweise des nicht multitasksicheren Objekts sowie ohne interne Kenntnisse darüber. Die Routine beginnt bei Schritt 1800. Am nicht multitasksicheren Objekt wird ein Verfahrensaufruf durchgeführt, der vom multitasksicheren Objekthüller "gefangen" und implementiert wird; Schritt 1802. Bei Schritt 1804 überprüft das Hüllenobjekt, ob irgendwelche nicht-multitasksicheren Objekte aus einer internen "Sammlung" an Objekten, die vom Hüller gehalten werden, momentan in Verwendung stehen. Wenn momentan keine Objekte verfügbar sind, wird eines bei Schritt 1806 konstruiert (eine andere mögliche Implementation könnte darin bestehen, zu sperren und darauf zu warten, daß ein anderes Objekt in der Sammlung verfügbar wird). Nachdem ein verfügbares Objekt erhalten wurde, wird die gewünschte Operation unter Verwendung des nicht multitasksicheren Objektes ausgeführt, wie dies in Schritt 1810 dargestellt ist. Nachdem die Operation abgeschlossen ist, wird das interne Überwachungsprogramm freigegeben, Schritt 1812, und die Routine wird abgeschlossen, Schritt 1814.
• Fig. 19 ist ein Flußdiagramm einer beispielhaften Routine, die vom Ansichtssystem verwendet wird, um mit dem Eingabesystem zu interagieren und ein Positionsereignis an sein Bestimmungsansichtsobjekt zu verteilen. Um dieses Flußdiagramm zu vereinfachen, werden keine besonderen Verteilungsregeln geschaffen oder verwendet. Die Routine beginnt bei Schritt 1900. Bei Schritt 1902 wird ein Positionsereignis vom Eingabesystem, welches das Ereignis von einer Einrichtung, die Positionsereignisse erzeugt, wie zum Beispiel einem standardmäßigen Mausgerät, empfangen hat, an das Ansichtssystem übergeben. Die Sperrung des Ansichtsüberwachungsprogramms erfolgt bei Schritt 1904. Das Ansichtssystem verwendet danach die Ansichtshierarchie und eine Gruppe von erweiterbaren Regelobjekten, um zu bestimmen, in welcher Ansicht der Punkt enthalten ist. Das Ansichtssystem stellt sicher, daß der Punkt in der "ersten" (Wurzel-) Ansicht enthalten ist; Schritt 1906. Das Betriebssystem hätte das Positionsereignis nicht an dieses Fenster weitergegeben, wenn der Punkt nicht innerhalb der Grenzen dieses Fensters läge; daher sollte der Test für die Wurzelansicht immer Wahr zurückgeben. (Wenn aus irgendwelchem Grund Falsch zurückgegeben wird, besteht die Möglichkeit, daß ein Fehler in einem Abschnitt des Betriebssystems vorhanden ist.) Nachdem festgelegt wurde, daß sich das Positionsereignis innerhalb der Wurzelansicht befindet, bestimmt das Ansichtssystem, ob der Punkt innerhalb einer Kind-Ansicht der Wurzelansicht enthalten ist; Schritt 1910. Wenn der Punkt nicht innerhalb einer Kind-Ansicht liegt, handelt es sich bei dem "Ziel" für das Positionsereignis um die aktuelle Ansicht. Wenn der Punkt innerhalb einer Kind- Ansicht enthalten ist, bestimmt das Ansichtssystem, um welche Kind-Ansicht es sich handelt; Schritt 1910 und 1914, und wiederholt dies solange (zurück zu 1906 usw.), bis die richtige, vorderste Ansicht gefunden wird, die das Positionsereignis enthält. Nachdem das Ziel gefunden wurde, wird das Ansichtsüberwachungsprogramm bei Schritt 1916 freigegeben, und das berechnete Ziel wird bei Schritt 1918 zum Eingabesystem zurückgegeben, das alle weiteren Verarbeitungsschritte für das Ereignis übernimmt. Die Routine wird bei Schritt 1920 abgeschlossen.
• Fig. 20A und 20B sind Flußdiagramme veranschaulichender Routinen, die vom Hintergrundaktualisierungsrahmenwerk verwendet werden, um Änderungen im Anzeigebereich eines oder mehrerer Ansichtsobjekte im Ansichtssystem zu sammeln, zu stapeln und zu verarbeiten. In Fig. 20A beginnt die Routine bei Schritt 2000. Wenn eine Änderung in einem Ansichtsobjekt auftritt, das momentan in der Ansichtshierarchie eingebaut ist, wird eine Benachrichtigung über diese Änderung bei Schritt 2002 an das Ansichtssystem geschickt. Das Ansichtssystem nimmt das Ansichtsüberwachungsprogramm bei Schritt 2004 in Besitz und prüft danach, ob Änderungen momentan für das Ansichtssystem "gestapelt" werden; Schritt 2006. (Wenn sich das Ansichtssystem im "Stapel"-Modus befindet, wird jedes Neuzeichnen, das aufgrund von Ansichtssystemänderungen notwendig sein könnte, vom Ansichtssystem gesammelt und zur späteren Verarbeitung durch das Hintergrundaktualisierungsrahmenwerk gespeichert. Wenn zur Zeit keine Stapelung verwendet wird, werden Aktualisierungsanforderungen sofort zum Hintergrundaktualisierungsrahmenwerk geleitet und verarbeitet. Wenn Änderungen gestapelt werden, wird in Fig. 20A die Änderungsbenachrichtigung zur Liste der Änderungen hinzugefügt, die für einen späteren Versand gespeichert wird; Schritt 2010. Wenn momentan keine Änderungen gestapelt werden, wird die Änderungsbenachrichtigung sofort an alle Objekte geleitet, die ein Interesse an diesen Änderungen angemeldet haben; Schritt 2008. Nachdem die Änderungsbenachrichtigung behandelt wurde (entweder gespeichert oder verteilt), wird das Ansichtsüberwachungsprogramm bei Schritt 2012 freigegeben, und die Routine wird bei Schritt 2014 beendet. Fig. 20B zeigt die Routine, die zur Verarbeitung von Änderungsbenachrichtigungen verwendet wird, nachdem die Stapelung abgeschaltet wurde. Die Routine beginnt bei Schritt 2020. Bei Schritt 2022 wird die Stapelbedingung geändert, damit alle noch nicht verarbeiteten Änderungsbenachrichtigungen weitergeleitet werden können. Das Ansichtssystem nimmt das Ansichtsüberwachungsprogramm bei Schritt 2024 in Besitz, verschickt alle gespeicherten Änderungsbenachrichtigungen bei Schritt 2026 und gibt dann bei Schritt 2028 das Ansichtsüberwachungsprogramm wieder frei. Die Routine wird bei Schritt 2030 abgeschlossen.
• Fig. 21A ist ein schematisches Diagramm, und Fig. 21B ein Flußdiagramm des Mechanismus, der vom Ansichtssystem verwendet wird, um einen Nur-Lesen- und einen Lesen- Schreiben-Zugriff auf die Ansichtshierarchie zu ermöglichen. Fig. 21A zeigt, daß Iteratorobjekte 2100 nur auf Nur-Lesen-Verfahren 2104 der Ansichtshierarchie 2108 Zugriff haben. Modifiziererobjekte 2102 haben sowohl auf Nur- Lesen-Verfahren 2104 des Ansichtshierarchieobjekts 2108 als auch auf Lesen-Schreiben-Verfahren 2106 (Verfahren, welche die Hierarchie modifizieren können) des Ansichtshierarchieobjektes 2108 Zugriff. Fig. 21B zeigt die Schritte, die in einer Musteroperation eines Iteratorobjektes ausgeführt werden (die verwendet wird, um die Gesamtfläche aller Kind- Ansichten der Ansicht zu berechnen). Die Routine beginnt bei Schritt 2150. Das Ansichtsobjekt konstruiert ein Itera torobjekt bei Schritt 2152. Mit Hilfe des Iteratorobjektes holt die Ansicht den Bereich für jede ihrer direkten Kind- Ansichten und fügt diese zum Gesamtbereich hinzu; Schritt 2154. Nachdem die Operation abgeschlossen ist, wird der Iterator bei Schritt 2158 zerstört, und die Routine wird bei Schritt 2160 beendet. Aufgrund der Tatsache, daß die Iterator- (und Modifizierer-) Objekte die notwendigen Überwachungsprogramme aus ihrer internen Implementation in Besitz nehmen und freigeben, werden keine Überwachungsprogramme (oder Semaphoren) benötigt.

Claims (14)

1. Eine Einrichtung (100) zur Verarbeitung einer Anforderung, die von einer Task einer Multitasking-Anwendung (102) erzeugt wird, zur Benutzung eines Nicht-Multitasking- Zielobjekts (506) in einem Computersystem, das einen Prozessor (302), einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (304, 306) und ein Multitasking-Betriebssystem (106) aufweist, das in dem Speicher läuft zur Steuerung des Prozessors, die Einrichtung umfaßt:

(a) durch das Multitasking-Betriebssystem (106) gesteuerte Mittel zum Erzeugen eines ersten Multitasking-Hüllenobjekts, das eine Sammlung von Nicht-Multitasking-Zielobjekten (1802) enthält;

(b) Bildschirm-Sperrobjekt-Mittel zum Verhindern eines gleichzeitigen Zugriffs durch zwei Tasks;

(c) Mittel, die im ersten Multitasking-Hüllenobjekt enthalten sind und auf eine Anforderung zur Benutzung eines Zielobjekts ansprechen zum Aufruf des Bildschirm-Sperrobjekts (1808);

(d) Mittel, die im ersten Multitasking-Hüllenobjekt enthalten sind und auf einen Aufruf des Bildschirm-Sperrobjekts ansprechen zur Benutzung eines der Zielobjekte (1804, 1810); und

(e) Mittel zum Freigeben der Bildschirmsperre, nachdem das eine Zielobjekt benutzt worden ist (1812).

2. Eine Einrichtung nach Anspruch 1, enthaltend Mittel, die auf die Anforderung zur Benutzung des einen Zielobjekts ansprechen zum Prüfen der Sammlung von Zielobjekten für eine Verwendung eines Zielobjekts, das nicht in Benutzung ist (1804).

3. Eine Einrichtung nach Anspruch 2, worin die Mittel zur Benutzung weiter Mittel enthalten zum Erzeugen eines Zielobjekts (1806), wenn kein Zielobjekt in der Sammlung von Zielobjekten verfügbar ist.

4. Eine Einrichtung nach Anspruch 3, worin die Mittel zur Benutzung weiter Mittel enthalten zum Benutzen des erzeugten Zielobjekts (1810).

5. Eine Einrichtung nach Anspruch 2, worin die Mittel zur Benutzung weiter Mittel enthalten zum Sperren der Anwendungstask, wenn kein Zielobjekt in der Sammlung von Zielobjekten verfügbar ist.

6. Eine Einrichtung nach Anspruch 5, weiter enthaltend Mittel zur Benutzung eines der Zielobjekte, wenn das eine Zielobjekt in der Sammlung von Zielobjekten frei wird.

7. Eine Einrichtung nach Anspruch 6, worin die Mittel zur Benutzung weiter Mittel enthalten zum Wiederaufnehmen der Anwendungstask, wenn das eine Zielobjekt in der Sammlung von Zielobjekten frei wird.

8. Ein Verfahren zur Verarbeitung einer Anforderung, die von einer Task einer Multitasking-Anwendung (102) erzeugt wird, zur Benutzung eines Nicht-Multitasking-Zielobjekts (506) in einem Computersystem, das einen Prozessor (302), einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (304, 306) und ein Multitasking- Betriebssystem (106) aufweist, das in dem Speicher läuft zur Steuerung des Prozessors, das Verfahren umfaßt die Schritte:

(a) Erzeugen eines ersten Multitasking-Hüllenobjekts, das eine Sammlung von Nicht-Multitasking-Zielobjekten (1802) enthält;

(b) Erzeugen eines Bildschirm-Sperrobjekt zum Verhindern eines gleichzeitigen Zugriffs durch zwei Tasks;

(c) Aufruf des Bildschirm-Sperrobjekts (1808) in Beantwortung einer Anforderung zur Benutzung eines Zielobjekts (1808)

(d) Benutzung eines der Zielobjekte in Beantwortung des Aufrufes des Bildschirm-Sperrobjekts (1804, 1810); und

(e) Freigeben der Bildschirmsperre, nachdem das eine Zielobjekt benutzt worden ist (1812).

9. Ein Verfahren nach Anspruch 8, worin der Schritt (d) den Schritt enthält:

(d1) Prüfen der Sammlung von Zielobjekten für eine Verwendung eines Zielobjekts, das nicht in Benutzung ist (1804).

10. Ein Verfahren nach Anspruch 9, worin der Schritt (d) weiter den Schritt enthält:

(d2) Erzeugen eines Zielobjekts, wenn kein Zielobjekt in der Sammlung von Zielobjekten verfügbar ist (1806).

11. Ein Verfahren nach Anspruch 10, worin der Schritt (d) weiter den Schritt enthält:

(d3) Benutzen des erzeugten Zielobjekts (1810).

12. Ein Verfahren nach Anspruch 9, worin der Schritt (d) weiter den Schritt enthält:

(d4) Sperren der Anwendungstask, wenn kein Zielobjekt in der Sammlung von Zielobjekten verfügbar ist.

13. Ein Verfahren nach Anspruch 12, worin der Schritt (d) weiter den Schritt enthält:

(d5) Benutzen eines der Zielobjekte, wenn das eine Zielobjekt in der Sammlung von Zielobjekten frei wird.

14. Ein Verfahren nach Anspruch 13, worin der Schritt (d) weiter den Schritt enthält:

(d6) Wiederaufnahme der Anwendungstask, wenn das eine Zielobjekt in der Sammlung von Zielobjekten frei wird.