Form_do-Routine: Eingabe mal anders

Die form_do-Routine des AES ist beim Arbeiten mit Dialogboxen ein praktisches Hilfsmittel, um die Kommunikation des Atari ST mit dem Benutzer zu erleichtern. FORM_DO übernimmt die komplette Verwaltung der Objekte innerhalb einer Dialogbox. Was aber, wenn man während des Dialogs zusätzliche Aktionen (z.B. eine eigene Tastaturabfrage) durchführen will?

Oder wenn man das Aussehen von “Standardobjekten” verändern will? Hier kommt man mit der eingebauten form_do-Routine nicht weiter, sondern muß sich eine eigene Eingabe programmieren.

Bei der Programmierung von Dialogen nimmt uns das GEM mit seiner form_do-Routine einen Großteil der Arbeit ab. Ist die Dialogbox einmal per Resource Construction Set erstellt, wird nach dem Zeichnen dieses Objekts (mit Hilfe von objc_draw) einfach die form_do-Routine des AES aufgerufen, und der Dialog mit dem Benutzer läuft automatisch ab. Das Hauptprogramm erhält erst wieder die Kontrolle, wenn die Dialogbox über ein EXIT- oder TOUCHEXIT-Objekt verlassen worden ist.

Vielleicht haben Sie sich aber schon die Frage gestellt, wie es manche Programme (z.B. das DISKUS-Diskutility oder der TEMPUS-Text-Editor) realisieren, die Buttons innerhalb einer Dialogbox auch über die Tastatur zu erreichen. Dies ist nur über eine neue Eingaberoutine möglich, die die vorhandene form_do-Routine ersetzt und neue Funktionen ermöglicht.

Was muß eine solche Eingaberoutine leisten? Zunächst müssen Eingaben oder Änderungen, die über die Tastatur oder die Maus hervorgerufen werden, auf dem Bildschirm dargestellt werden. Wird also eine Taste gedrückt, muß das der Taste entsprechende alphanumerische Zeichen in das aktuelle Eingabefeld der Dialogbox übertragen werden. Anschließend muß der Eingabe-Cursor auf die nächste Zeichenposition gesetzt werden. Handelt es sich bei der gedrückten Taste um die Tabulator- oder eine Cursor-Taste, muß ein Wechsel der Eingabeposition oder des -feldes erfolgen. Weiterhin muß sich der Programmierer darum kümmern, daß der Cursor innerhalb von Eingabefeldern an der richtigen Stelle dargestellt wird.

Schließlich müssen auch Mausaktionen überwacht werden. Wird ein EXIT- oder TOUCHEXIT-Button angeklickt, muß der Dialog beendet werden. Handelt es sich um einen Radio-Button, muß dies insofern berücksichtigt werden, als nicht nur der Status des angeklickten Buttons geändert werden muß, sondern auch andere Radio-Buttons einen neuen Objektstatus erhalten müssen.

Sie sehen, es gibt viel zu beachten. Glücklicherweise besitzt das AES genügend Unterroutinen, um bei der Verwendung einer eigenen Dialogroutine die Überwachung der oben aufgeführten Eingaben zu erleichtern. Insbesondere spreche ich damit die Funktionen form_keybd, form_button und objc_edit an. In Verbindung mit diesen (leider häufig nur unzureichend dokumentierten) AES-Routinen läßt sich eine Eingaberoutine formulieren, die einige neue Möglichkeiten zur Verwaltung von Dialogen bietet und vom äußerem Erscheinungsbild her wie eine “normale” Dialogbox wirkt.

Damit die folgenden Ausführungen nicht graue Theorie bleiben, soll anhand des Beispielprogramms DIALOG aufgezeigt werden, wie die Programmierung einer eigenen form_do-Routine vonstatten gehen kann. DIALOG stellt eine Dialogbox auf dem Bildschirm dar, die aus zwei Eingabefeldern, zwei Radio-Buttons sowie einem “OK"- und einem "ABBRUCH"-Button besteht. Die Buttons können wie üblich über die Maus bedient werden, und auch sonst bestehen auf den ersten Blick keine Unterschiede zu anderen Dialogboxen.

Wie sieht es auf den zweiten Blick aus? Nun, Radio-Button 1 kann nicht nur über die Maus, sondern auch über die Tastenkombination [ALTERNATE] [1] betätigt werden, Radio-Button 2 ist über [ALTERNATE] [2] ansprechbar. Darüber hinaus kann der "ABBRUCH"-Button über die [Undo]-Taste erreicht werden.

Das ausführlich kommentierte Assembler-Listing zu DIALOG.PRG möchte ich nun als Grundlage nehmen, um die Programmierung einer eigenen Dialogroutine zu erläutern. Wie bereits erwähnt, bilden die AES-Routinen form_keybd und form_button das Kernstück des Programms. form_keybd ermöglicht es, in einer Dialogbox Tastatureingaben zu simulieren, mit form_button kann die Betätigung eines Mausknopfes simuliert werden. Damit man die Möglichkeit hat, während des eigentlichen Dialogs zusätzliche Aktionen vorzunehmen, geschieht die Abfrage von Tastatur und Maus nun nicht mehr über die eingebaute form_do-Routine des AES, die ja Manipulationen während des Dialogs nicht zuläßt, sondern über die evnt_multi-Routine. Allgemein können über evnt_multi diverse Benutzeraktionen überwacht werden. Um zu spezifizieren, worauf evnt_ multi konkret achten soll, wird ein Parameterwort übergeben, in dem je nach zu überwachender Aktion entsprechende Bits gesetzt sind. Nach diesem AES-Aufruf überwacht GEM für uns so lange Tastatur und Maus, bis eine Aktion (Tastendruck oder Betätigung der Maustaste) seitens des Benutzers erfolgt. Erst dann wird die Programmkontrolle wieder an das Hauptprogramm zurückgegeben. Ist dies geschehen, so finden sich in einem eigens für den evnt_multi-Aufruf errichteten Array (in unserem Fall ev_buff) Angaben über die Art der Aktion. Wie bereits beim Aufruf von evnt_multi werden diese Daten wieder durch einzelne Bits repräsentiert.

Tabelle 1: Organisation eines Objektes

DIALOG.PRG verzweigt nun, je nachdem, um welche Aktion es sich gehandelt hat, in eine Routine zur Behandlung von Mausaktionen oder kümmert sich um die Taste, die vom Anwender gedrückt wurde. Beschäftigen wir uns zunächst mit dem Fall, daß evnt_multi einen Tastendruck gemeldet hat. ASCII- und Scancode der gedrückten Taste werden uns im ev_buff-Array mitgeteilt. Liefert evnt_multi einen gültigen ASCII-Code zurück, handelt es sich um eine “normale” alphanumerische Eingabe, und das Zeichen kann direkt in die Dialogbox geschrieben werden. Ist der ASCII-Code jedoch Null, liegt also nur der Scancode der betätigten Taste vor, geht es nun darum, festzustellen, ob ein Button existiert, der durch diese Taste bedient werden kann.

Um Buttons über die Tastatur bedienen zu können, werden bei DIALOG.PRG Tastenkombinationen zusammen mit der [ALTERNATE]-Taste verwendet, da in diesem Fall von evnt_multi nur der Scancode der Taste, jedoch kein ASCII-Code zurückgeliefert wird. Natürlich muß man an geeigneter Stelle eine Information unterbringen, welcher Button durch welche Taste bedient werden kann. Es ist sehr praktisch, diese Zusatzinformation innerhalb der Objektdaten der Dialogbox unterzubringen. Wie ein Objekt organisiert ist, läßt sich in Tabelle 1 sehen [ 1 ].

Im Wort für den Objekttyp ist nur das Low-Byte belegt. Somit steht das High-Byte für eigene Anwendungen zur Verfügung. DIALOG.PRG macht sich dies zunutze, indem es bei Buttons, die über die Tastatur bedient werden können, im High-Byte des Objekttyps den Scancode der Taste erwartet, durch die der betroffene Button angesprochen werden kann. Das Programm durchsucht nun einfach den gesamten Objektbaum auf ein Objekt, bei dem als erweiterter Objekttyp der Scancode der Taste eingetragen ist, die gedrückt wurde. Findet sich ein solches Objekt nicht, wird zum Schleifenanfang zurückgekehrt und der Dialog fortgesetzt. Ist ein Objekt vorhanden, das über die gedrückte Taste angewählt werden kann, wird die Objektnummer berechnet und über evnt_button ein Mausklick auf dieses Objekt simuliert. Der Effekt eines Tastendrucks in Verbindung mit der [ALTERNATE]-Taste ist somit der gleiche wie beim Anklicken eines Buttons mit der Maus.

Wurde ein alphanumerisches Zeichen (also ein Tastendruck ohne Kombination mit der [ALTERNATE]-Taste) eingegeben. wird mit den ASCII-und Scancodes für dieses Zeichen zunächst die form_keybd-Routine aufgerufen, die in der Lage ist, diesen Tastendruck für unsere Dialogbox aufzuarbeiten. Handelte es sich bei der gedrückten Taste um eine Cursor- oder die Tabulatortaste, liefert uns form_keybd die Nummer des Eingabefeldes zurück, in der wir nun den Text-Cursor positionieren müssen. Zusätzlich bekommen wir in diesem Fall eine Null als Rückgabewert, was bedeutet, daß keine Taste betätigt wurde, um deren ASCII-Darstellung wir uns kümmern müßten.

Erhalten wir keine Null zurück, sondern einen positiver Wert, so ist das Eingabefeld zwar das gleiche geblieben, aber dafür müssen wir an der aktuellen Cursor-Position ein ASCII-Zeichen eintragen. Dies geschieht mit Hilfe von objc_edit. Diese Funktion erlaubt es, Texteingaben in einem Formular vorzunehmen. Nach Aufruf dieser Routine mit dem ASCII-Code der gedrückten Taste wird das Zeichen in der Dialogbox dargestellt. Anschließend liefert uns objc_edit die neue Position des Text-Cursors zurück, der ja jetzt um eine Stelle nach rechts gerückt ist.

Falls evnt_multi abgebrochen wurde, weil ein Maus-Button betätigt wurde, ist zunächst zu prüfen, ob sich der Maus-Cursor überhaupt innerhalb der Dialogbox befindet. Hierzu können wir die objc_find-Funktion heranziehen. Die Koordinaten des Mauszeigers, die objc_find übergeben werden müssen, werden uns von evnt_multi in ev_buff zur Verfügung gestellt. Liefert objc_find einen Wert größer als Null zurück, befand sich der Mauszeiger innerhalb der Dialogbox. Andernfalls wird als Fehlersignal ein Glockenton ausgegeben, so wie es auch die “normale” form_do-Routine macht.

Tabelle 2: Die USERBLK-Struktur

Wurde ein Objekt innerhalb der Dialogbox angeklickt, wird AES dieser Umstand mittels form_button mitgeteilt. Das GEM übernimmt den Rest der Arbeit, kümmert sich also z.B. darum, ob es sich beim angeklickten Objekt um einen Radio-Button handelt. In diesem Fall wird nicht nur der selektierte Button invertiert, sondern die restlichen Radio-Buttons werden deselektiert. Handelte es sich beim selektierten Objekt um einen Exit-Button, liefert form button einen Wert von Null zurück. Ist dies der Fall, wird der Dialog beendet.

Wurde ein Objekt ausgewählt, das keinen Exit-Status besitzt, muß zunächst geprüft werden, ob es überhaupt selektiert werden darf und es sich nicht z.B. um einen String handelt. Stellt das angeklickte Objekt ein Eingabefeld dar, muß der Text-Cursor auf dieses Feld plaziert werden. Hier hilft die objc_edit-Routine weiter. Zunächst wird der Text-Cursor an der alten Stelle entfernt und anschließend an der neuen Eingabeposition dargestellt.

Nun noch zur Darstellung eigener Objekttypen, wie im Fall von DIALOG dem String, der von einer abgerundeten Box umgeben ist. Will man die Zeichenroutinen des AES umgehen und das Aussehen von Objekten weitgehend selber bestimmen, muß man mit benutzerdefinierten Objekten (G_USERDEF bzw. G_PROGDEF) arbeiten. Bei Objekten dieser Art zeigt ob_spec (s.o.) auf eine USER BLK-Struktur (s. Tabelle 2). Trifft das AES beim Erstellen eines Dialogs auf diesen Objekttyp, wird die Objektdarstellung nicht vom AES übernommen, sondern stattdessen eine Routine aufgerufen, deren Adresse vom Programmierer in der obigen Objektstruktur festgelegt werden kann. DIALOG.PRG nutzt nun VDI-Routinen (nur solche dürfen beim Zeichnen eigener Objekte aufgerufen werden!) dazu, Text und Rahmen des ersten Strings der Dialogbox in einem eigenen Format, also mit abgerundeten Ecken, darzustellen. Natürlich sind an dieser Stelle die verschiedensten Manipulationen denkbar.

Eine Frage ist jedoch noch offen geblieben: Wie bringe ich im High-Byte des Objekttyps eigene Informationen unter? Hier kommt es auf das verwendete Resource Construction Set an. Die Methode, den Objekttyp für eigene Daten zu nutzen, wird z.B. durch das Resource Construction Set von Kuma unterstützt. Hier hat der Anwender die Möglichkeit, für jedes Objekt einen sogenannten “erweiterten Objekttyp” (extended object type) anzugeben. Die Zahl, die man an dieser Stelle einträgt, findet sich im High-Byte des Objekttyps wieder.

Soweit meine Erläuterungen zur Programmierung einer eigenen form_do-Routine. Weitere Informationen können dem kommentierten Programm-Listing entnommen werden. Auf die GEM-Routinen. die zur Darstellung einer Dialogbox benötigt werden, bin ich nicht näher eingegangen, da diese Problematik bereits des öfteren in zurückliegenden Ausgaben des ST-Magazins angesprochen wurde. Der Einbau der vorgestellten Routine in eigene Programme gestaltet sich recht einfach, da im Grunde genommen nur der Aufruf der form_do-Routine des AES durch die neue Routine ersetzt werden muß.

Es dürfte keine große Schwierigkeit darstellen, die Grundidee der vorgestellten Dialogverwaltung in andere Programmiersprachen zu übertragen, da DIALOG.PRG in der Hauptsache Gebrauch von Systemroutinen macht, die ja in Hochsprachen ähnlich wie in Assembler angesprochen werden.

[1]: Jankowski, Reschke, Rabich: Atari ST Profibuch (Sybex-Verlag)