GFA Basic unterstützt GEM so, dass die Erstellung von Programmen sehr leicht ist. Und die GFA Systemtechnik wartet noch mit einem weiteren bonbon auf: Mitgeliefert wird ein komfortables Resource Construction Set, das RCS2.PRG. Dass es beim Start irgendwelche Dateien auf dem Laufwerk A: sucht, ist zwar nicht schön (besonders bei einer Harddisk), aber dem Programm nicht weiter abträglich.

So schön dieses Programm auch ist, die Ausgabe der benannten Objekte als LST-File handhabt es mit einer nicht zu übersehenden Formlosigkeit. Objektnamen und Bäume werden in der Reihenfolge geschrieben, in der sie benannt wurden. Wie ein solches LST-File mit 20 Bäumen und 300, 400 Objekten nach der 12. Änderung aussieht, kann sich wohl jeder denken. Ein Wust von Objektnamen, Baumbezeichnungen: Hinter dem Menüeintrag Nr. 32 in Baum 0 steht der Button aus Baum 15, der Name von Baum 0 steht irgendwo mittendrin, in Zeile 352...

Also, Möglichkeit Nr.1, dort Ordnung zu schaffen: Von jedem Baum eine Hardcopy, die Objekte numeriert und die Namen irgendwo auf dem Blatt mit der Nummer notiert. Für RSC-Dateien bis zu zwei Bäumen mit 20 Objekten kein Problem, zur Not merkt man sich die Namen auch so. Aber bei 80, 90, 100, 200 oder mehr Objekten dürfte es damit etwas schwierig werden.

Die zweite Möglichkeit zeigt mein Programm, das in dieses Chaos Ordnung bringt: Es sortiert das File.

Zuerst stehen die Bäume, der Nummer nach sortiert. Danach kommen für jeden Baum die Objekte (auch sortiert). Und damit die Schreibarbeit noch mehr vermindert wird, stehen für jedes Objekt noch der Typ und bei Textobjekten (also auch bei Buttons) die ersten 20 Zeichen dahinter. Außerdem werden bei jedem Objekt der Status, z.B. SELECTED - d.h. das Objekt ist invertiert dargestellt - und die gesetzten Flags wie EDITABLE, HIDDEN, TOUCHEXIT angegeben, allerdings als Kürzel. Davon jedoch später mehr. Die Angabe der Nummer des entsprechenden Baumes bleibt natürlich erhalten. Doch betrachten wir nun das Programm:

Zunächst setzen wir die Untergrenze der Arrays auf 1, damit späterhin die Sortierfunktion korrekt sortiert. Ohne diese Maßnahme bliebe das Element 0 immer leer und könnte die Routine stören. Dann werden etliche Arrays definiert, die Bestimmung der einzelnen Felder entnehmen Sie bitte den Kommentaren. Außerdem kommen wir bei einigen Feldern auf ihre Bestimmung noch zu sprechen. Als Eckdaten gelten:

zu verwaltende Objekte: max. 500
zu verwaltende Bäume: max. 30 Objekte
pro Baum: max. 150

Insgesamt mögen die Daten als etwas sehr hoch angesetzt erscheinen, doch habe ich selbst gemerkt, daß bei leistungsfähigen Dialogen und Dialogen zur Dateneingabe mit Leichtigkeit 100 Objekte Zusammenkommen. Doch weiter im Programm:

Zuerst wird das Includefile mittels RECALL in das Array a$() eingelesen. Dann müssen die Objekte grob vorsortiert werden, damit die Objekte gleicher Bäume zusammengefaßt werden können. Dabei werden die verstreuten Bäume auch gleich an die Spitze gestellt. Dazu müssen die Baumnummern, die zu den Objekten gehören, festgestellt werden. Wir bedienen uns des Formats der Anweisungszeilen:

Bei Objekten:

‘objcname&=
objnr !Obj in #baumnr’
z.B.: EXIT&=15 !Obj in #6

Bei Bäumen:

‘treename&=
treenr !RSC_TREE'
z.B.: DIALOG&=6 !RSC_TREE

Die Baumnummer steht also hinter dem '#’ (genannt Hash [häsch]). Bei Bäumen ist das nicht der Fall. Also stellen wir die Position des Hashs fest. Ist sie ungleich Null, liefert die VAL( )-Funktion des dahinter liegenden Teilstrings die Baumnummer des Objektes. Ist die Position Null, haben wir die Zuweisung einer Baumnummer vor uns und setzen das Element a&() auf minus eins.

Gleichzeitig setzen wir das entsprechende Array-Element a%() auf den Index i%. In der nun folgenden Sortierung wird neben dem Array a&() das Array a%() mitsortiert.

Wozu das alles?

Nehmen wir an, bei der Sortierung ist das Element a&(5) auf die Stelle 53 gelangt. Nun steht in a%(53) der Index 5, weil a%(5) ebenfalls auf die Stelle 53 verschoben wurde. Beim Umspeichern in das Array b$() muß in das Element b$(53) das Element a$(5) geschrieben werden. Genau dieser Index steht aber in a%(53)! Also heißt die Anweisungszeile b$(i%)=a$(a%(i%)). Ähnliche Zeilen werden wir noch öfter sehen.

Die Zuweisungen der Baumnummern stehen nach der Sortierung an der Spitze des Arrays b$(), weil die entsprechenden a&()-Elemente gleich minus eins sind.

Die Anzahl der Bäume wird danach ermittelt. Solange das nächste a&()-Element gleich minus eins ist, wird die Variable t% um eins erhöht. Danach wird die Variable ende% auf t% gesetzt. Nun werden noch einige benötigte Felder dimensioniert, die für die weitere Bearbeitung nötig sind. Was nun abläuft, haben wir am Anfang ganz genau betrachtet, so daß wir uns um die Sortierung der Bäume nicht mehr zu kümmern brauchen. Für die weitere Bearbeitung ist die Speicherform des eindimensionalen Feldes (Vektor) schlecht geeignet. Besser geeignet ist nun ein zweidimensionales Array, auch Matrix genannt. In der Matrix gibt es Zeilen und Spalten, sie ist also praktisch eine Tabelle. Nun speichern wir die Objektindizes so ab, daß in den Spalten der ersten Zeile alle Objekte des ersten Baumes stehen. In der zweiten Zeile stehen dann alle Objekte des zweiten Baumes usw. In der gleichen Art werden auch die Zuweisungszeilen gespeichert. Gleichzeitig werden auch die Objekte eines Baumes mittels des Vektors obj_count&() gezählt.

Jetzt ist alles bereit, und die RSC-DATEI kann geladen werden. Nachdem diese im Speicher steht, werden mit ~RSRC_GADDR die Adressen der Bäume, deren Nummern in t&() stehen, in t%() gespeichert. Nun ist alles nur noch halb so schwer, wie es aussieht. Systematisch werden die Objekttypen der Objekte festgestellt. Dabei wird der Startwert beginge der inneren i%-Schleife bei jedem erfolgreichen Durchlauf auf den um eins erhöhten aktuellen i%-Wert gesetzt. Gleichzeitig wird das Flag ex! auf FALSE (logisch falsch) gesetzt, damit die Schleife nicht verlassen wird.

Beim nächsten Durchlauf wird sie wieder auf TRUE gesetzt, damit im Falle eines erfolglosen Durchlaufs die Schleife sofort verlassen wird. In begin% steht nun der i%-Wert, bei dem die Schleife verlassen wurde und bei dem der Wiedereinstieg erfolgen muß, da wir den nächsten Baum bearbeiten. Diese optimale Bearbeitung ist aber nur deshalb möglich, weil alle Objekte eines Baumes durch die grobe Vorsortierung direkt hintereinander stehen und nicht im gesamten Vektor b$() verstreut sind. Diese Routine ist die zeitkritischste im Programm. Ersetzen Sie begin% durch ende%+1, so braucht die Routine je nach Dateigröße bis über das Doppelte an Zeit.

Anschließend wird die Zuweisungszeile um die Angabe des Objekttyps erweitert, die Vorgehensweise dürfte keine Verständnisprobleme aufwerfen. Wenn es sich beim Baum um einen Menübaum handelt und das Objekt vom Typ STRING ist, haben wir es mit einem Menüeintrag, neudeutsch ENTRY genannt, zu tun und nennen ihn auch so. Einen Menübaum erkennen wir daran, daß das dritte Objekt ein G_TITLE ist (OB TYPE(tree%,3)=32).

Dann benötigen nur noch die Zeichenketten der Textobjekte wie STRING, TEXT, BOXTEXT, FTEXT (EDIT), FBOXTEXT (BOXEDIT), BUTTON. Bei STRING und BUTTON liefert uns OB_SPEC(tree%,obj&) die Adresse des entsprechenden Strings. Die Funktion CHAR{} liest den String an dieser Adresse aus. Bei den anderen Textobjekten liefert uns OB_SPEC() 'nur' die Adresse eines Zeigers, der die Adresse des uns interessierenden Strings enthält. Deshalb wird CHAR{{}} verwendet. Die Leerzeichen links und rechts dieses Strings werden mit TRIM$() gelöscht (soweit vorhanden) und die ersten 20 Zeichen an die Befehlszeile angehängt. Nun werden Status und Flags der Objekte abgefragt, indem die einzelnen Bits der entsprechenden Strukturen mittels BTST() getestet werden. Ein Objektstatus wird in Großbuchstaben geschrieben und mit einem Slash (‘/’) getrennt, während bei den Flags Kleinbuchstaben und ein ‘I’ Verwendung finden. Hier sind alle Kürzel aufgeführt:

/SLCT:SELECTED /CRSS:CROSSED /CHCK:CHECKED /D'ABL: DISABLED /OUTLN:OUTLINED /SHWD:SHADOWED |slctbl:SELECTABLE |default:DEFAULT |exit:EXIT |edit:EDITABLE |radio :RBUTTON |last :LASTOB |touch:TOUCHEXIT |hide :HIDETREE (HIDDEN)

Alle Kürzel auf einen Blick

Damit sind wir fast am Ende des eigentlichen Programms. Zum Schluß werden auf die altbekannte Art und Weise die Objekte jedes Baumes sortiert. Danach werden die Objektbaumnummern in der richtigen Reihenfolge gespeichert und wieder in den Vektor b$() zurückgeschrieben. Die ersten ende%-Elemente sind die Objektbäume. Schließlich werden die ergänzten und sortierten Zuweisungszeilen aus dem Array obj_line$() in den Vektor b$() geschrieben. Die eigentliche Routine ist nun beendet. Der Rest sind kleine Routinen, die nicht weiter schwierig zu verstehen und außerdem ausführlich dokumentiert sind.

Bei der Ausgabe erfolgt zunächst die Angabe der Objektbäume. Danach ist es möglich, sich die Bäume anzeigen zu lassen. Haben wir kein Menü vor uns, so wird der Baum zentriert, bevor er angezeigt wird. Die Bäume werden ausnahmslos mittels OBJC_DRAW() aufgebaut, so werden Schwierigkeiten mit der Menüverwaltung vermieden.

Zum Abschluß sei noch ein Wort zum Programm selbst gesagt: Natürlich kommt Unsinn zustande, wenn Include -file und RSC-Datei nicht zueinandergehören, Tests auf diesem Gebiet sind also unnötig. Auch sollte ein Menü immer an erster Stelle im Resource stehen. Genauso ist es auch möglich, aus dem RSC-Header die Anzahl der Bäume direkt auszulesen. Doch das ist nur interessant, wenn kein Includefile vorhanden ist, wie es bei einem RSC-Analyser der Fall ist. Das vorliegende Programm soll nur zeigen, was mit den Sortierungsroutinen gemacht werden kann und wie Schlüsselfelder benutzt werden. Zudem ist das Programm in meinen Augen ein gutes, einfaches und sinnvolles Beispiel, wie bequem in GFA BASIC 3.xx Objekte behandelt werden können.

Literatur:

Szczepanowski,
Das große GEM-Buch zum ATARI ST
DATA BECKER Verlag 1985

GFA BASIC 3.0 Handbuch