★ CODING ★ BENUTZEROBERFLAECHE CEUS V1.0 - TEIL 3: DER WINDOW MANAGER (KOMPLETT) (CPC AMSTRAD INTERNATIONAL) ★ |
| Menu - RSX | Benutzeroberflaeche CEUS v1.0 - Teil 3: Der Window Manager (komplett) (CPC Amstrad International) |
In der letzten Folge haben wir die grundsätzlichen Befehle zur Programmierung einer grafischen Benutzeroberfläche entwickelt. In dieser Folge kommen nun noch einige Erweiterungen zum Window Manager dazu; denn Grundlagen ohne Extras sind wie Suppe ohne Salz... Haben Sie fleißig die Hausaufgaben aus der letzten Folge gemacht? Nein? Auch nicht so schlimm, denn hier kommen einige absolut nützliche Erweiterungen für Ihren Window Manager. Erinnern wir uns: In der letzten Folge haben wir einige Routinen kennengelernt, mit deren Hilfe wir so nette Dinge erledigen konnten wie Bildausschnitte retten, Windows zeichnen, Schatten werfen und Fenster öffnen und schließen. Damit lassen sich schon ganz nette Programme schreiben, aber es kommt noch besser. Überlegen wir einmal: Wofür verwendet man normalerweise ein Window (jetzt denken Sie doch nicht gleich wieder an Multitasking, das wäre beim CPC ein wenig illusorisch)? Also, da gibt es einmal Menüs, dann Meldungen und natürlich Arbeitswindows, in denen Utilities und Unterprogramme ihre Meldungen zum besten geben, oder Fenster, in denen mehrere Funktionen eines Programms ablaufen, wie zum Beispiel mehrere Texte in einer Textverarbeitung oder eine Hilfeseite. Die Menüs und die Systemmeldungen kommen später, und die verschiedenen Textbereiche sind mit den bisherigen Befehlen kein Problem. Aber der Rest! Stellen wir uns einmal vor, wir haben eine Anwendung, in der ein Notizblock und ein Kalender integriert sind. Der Kalender erscheint jetzt auf dem Bildschirm, und damit jeder weiß, daß es sich um einen Kalender handelt, soll das im Fenster vermerkt werden. Das Fenster beim Namen genannt Das Kalender-Window muß also einen Namen bekommen. Ist kein Problem, man muß nur das Fenster etwas vergrößern. eine Überschrift oben hinein formatieren, mit einer schönen Linie abgrenzen und das Fenster wieder verkleinern. Und hinterher beim Ausblenden hat man auch daran zu denken. Ist wohl doch nicht so einfach. Das wäre doch eine schöne Aufgabe für eine fertige Routine: Man sagt einfach: |WINDOW.NAME, num, x1, y1, x2, y2, @name$Den Rest erledigt der Window Manager. Die Routine geht dabei so vor, daß sie zuerst die obere Window-Grenze um zwei verkleinert und dann mit fünf Parametern (ohne name$) |WINDOW.OPEN aufruft. Danach wird im neuen Window der Name ausgegeben (an der Oberkante, zentriert), eine Linie aus Zeichen 154 drunter gezogen und das System-Window (# num) wieder auf die ursprüngliche Größe verkleinert. Fertig.
Tarnkappe her Aber es gibt ja auch noch andere Aufgaben. Kehren wir zurück zu obiger Situation. Wir haben unsere Anwendung, und darüber liegt ein Kalender und darüber ein Notizblock. Nun wollen wir schnell, während wir im Notizblock arbeiten, auf den Kalender schauen. Dazu extra den Notizblock zu schließen, auf den Kalender zu schauen, den Notizblock wieder zu öffnen und komplett neu aufzubauen, das erscheint da ein wenig umständlich. Besser ist, den Notizblock kurz auszublenden. um einen Blick auf die geschlagenen Stunden zu werfen. Theoretisch ist das alles wieder ganz einfach: Statt des Hintergrundes retten wir einmal den Vordergrund, blenden das Fenster aus, schauen den Kalender an, retten wieder den Hintergrund und blenden den Vordergrund ein. Ein scheinbar plausibler Schritt, der bei näherer Rechnung seine Vorteile verliert: Unser Notizblock ist (Mode 1) 30 mal 20 Zeichen groß. Dann belegt er im Speicher alleine schon 11 kByte, dasselbe noch mal für den Vordergrund, und der Kalender ist auch noch da. Da wird es schon sehr eng. Aber eigentlich muß das ja nicht sein! Während wir den Vordergrund retten, blenden wir den Hintergrund ja wieder ein, er braucht also nicht im Speicher gehalten zu werden, und wir können seinen Bereich für den Vordergrund verwenden. Wir brauchen nur den gespeicherten Hintergrund gegen die Bilddaten auszutauschen und erreichen eine wesentlich elegantere Lösung. Das heißt, ganz so einfach ist das auch wieder nicht. Das Fenster hat ja noch einen Schatten, und dessen Hintergrund ist auch gerettet. Wenn wir jetzt einfach zweimal tauschen, steht vorher und nachher derselbe Schatten da, und wenn sich der Hintergrund inzwischen geändert hat, dann stimmt er nicht mehr. Wir können also den Schatten nicht mit retten (den Rahmen auch nicht), sondern müssen sie beim Wiederaufbau neu berechnen. Das bedeutet, daß wir für diese Bereiche sowohl beim Aus- als auch beim Wiedereinblenden Sonderbehandlungen durchführen müssen. Das Berechnen des Rahmens und des Schattens wiederum können wir der WINDOW.DRAW-Routine überlassen. Wir müssen nur den Aufruf zum Löschen des Fensterinhaltes unterbinden, weil dieser schon vorher eingeblendet wird (er muß für den Hintergrund Platz machen). Ansonsten sollten wir nur noch ein Flag setzen, ob ein bestimmtes Fenster nun eigentlich dargestellt ist oder nicht, denn wenn man dasselbe Fenster zweimal verstecken würde, gäbe es Chaos. Ach ja, und noch was: So ganz problemlos ist diese Routine auch nicht, denn der Benutzer muß selbst aufpassen, daß sie nicht auf Fenster angewandt wird, die ganz oder teilweise verdeckt sind, denn sonst würden diese zerstört. Die Befehle zum Verstecken und Wiederherstellen heißen |WINDOW.HIDE,num und |WINDOW.SHOW,num und erwarten als Parameter nur die Nummer eines eröffneten und dargestellten (bzw. nicht dargestellten, bei IWINDOW.SHOW) Fensters. Mit diesen Befehlen lassen sich jetzt schon aufwendigere Dinge programmieren. Aber was? Gehen wir noch einmal zurück zu unserem Beispiel von vorhin: Sie haben den Notizblock und darüber liegt der Kalender. Jetzt wollen sie den Notizblock bearbeiten, ohne daß der Kalender verschwindet. Sie brauchen also einen Befehl, der ein Fenster unter einem anderen hervorholt und dabei die Window-Tabelle korrigiert; denn es kann ja immer nur das oberste Fenster geschlossen werden. Das klingt insgesamt relativ einfach, ist aber doch recht aufwendig zu programmieren. Aber warum denn? Man muß doch nur... ja, was denn eigentlich? Zuerst müssen (von oben her) sämtliche Fenster, die über unserem Window liegen (in der Tabelle), versteckt werden, dann unser spezielles Window, und danach müssen alle oberhalb liegenden Fenster in der umgekehrten Reihenfolge wieder dargestellt werden. Zuletzt folgt wieder das hochzuholende Fenster. Der Haken kommt hinterher: Die gesamten Tabellen für die Window-Ordnung müssen korrigiert werden, daß heißt, die Einträge für unser Fenster werden gerettet, die nachfolgenden um einen Platz nach unten kopiert und unsere geretteten Einträge hinten angehängt. Und danach bekommt unsere beliebte MEM-FRE-Routine Zuwachs: Weil nach dem Poppen das oberste Window ja nicht mehr mit dem untersten im Speicher übereinstimmen muß, müssen wir eventuell neben den Symboltabellen auch noch die Windows verschieben. The End Das wär's eigentlich für diesmal, in der Tabelle sind nochmal alle Befehle auf einen Blick zusammengefaßt. Hausaufgaben für all die, die es nicht abwarten können, gibt es auch wieder. Diesmal lautet unser Vorschlag auf eine Routine zum Verschieben eines Windows. Man muß zunächst auch - wie beim Poppen -alle oberhalb liegenden Windows ausblenden, dann das entsprechende Fenster verstecken, die internen Koordinaten ändern und alle Fenster wieder darstellen. Oder wie wär's mit einem Befehl, der ein Window unter anderen hervorholt, ohne sie erst auszublenden. Der müßte dann aber an deren Hintergrunddaten heran, und zwar mit Schatten und allem, was dazugehört. Das ist wohl nur etwas für diejenigen, die mit ihrem Assembler absolut fit sind, aber nicht unmöglich... In der nächsten Folge gibt's dann etwas Neues: die Bildschirmsteuerung für den CPC. Mit allem. was das kommandozeilengeplagte Programmiererherz verlangt, wie Cursorsteuerung (mit Cursortasten, Joystick oder AMX-Maus) und einer komfortablen Icon-Steuerung.
| ||||||||||||||||||||||||||||||||||
