Es heißt doch immer: “Der ATARI ST zeichnet sich gerade durch seine anwenderfreundliche Benutzeroberfläche GEM aus..” Aber was kann ich dafür, wenn ich mich mit diesem komplizierten Zeug nicht auskenne!
So mag es sicherlich schon vielen Programmierern ergangen sein, als sie den Einstieg in die Welt der GEM-Juwelen wagen wollten. Nur was hilft dieses “Zauberwort GEM”, wenn man Schwierigkeiten hat, dieses “Juwel” auch zu benutzen? Früher mußte der Programmierer durch eine Vielzahl von Überwachungsmaßnahmen unter hohem Aufwand einzelne GEM Objekte verwalten. Und genau dies war das Problem, warum die meisten vor GEM zurückschreckten.
Zwar wurde immer wieder versucht, den BASIC-Programmierern Hilfestellung zu geben, sei es durch Zeitschriften (siehe auch unseren GEM-Kurs in der 2. Jahreshälfte 1987) oder durch GFA, indem GEM-Funktionen als Befehle ins GFA-BASIC 3.0 aufgenommen wurden, aber dennoch trugen diese Maßnahmen nur vereinzelt Früchte...
Wohl am Vorbild der “Easy-GEM-Library” für OMIKRON.BASIC-Programmierer orientierte sich die GFA-Systemtechnik und schuf ihr neuestes Produkt, das "GFA-GEM-Utility-Package”, von dem betriebsintern einfach nur als “GUP” die Rede ist. Es besteht aus vielen Prozeduren, die für die Verwaltung einzelner GEM-Aufgaben nötig sind. Das Programm-Paket wurde nun durch GFA von der niederländischen Originalversion ins Deutsche übersetzt.
Mittels Prozeduren wird es für den GFA-BASIC-Programmierer nun zum Kinderspiel, GEM zu handhaben und seine Programme anwenderfreundlicher zu gestalten. Von der Verwaltung einer Dialogbox über Pull-Down-Menüs und eigene Desktops mit einer Icon-Verwaltung bis hin zum komfortablen Arbeiten mit Text- und Grafikfenstern - kein Bereich wurde ausgespart. Beim GEM-Utility-Package handelt es sich um ein sogenanntes "Rahmen-Programm”, das in GFA-BASIC geschrieben wurde. Der Programmierer muß einen Teil des Rahmens selbst formen, indem er einzelne Prozeduren seinen Wünschen gemäß “ausfüllt”.
Bevor Sie sich als Programmierer an die Erstellung eines GEM-Programmes machen, sollte zunächst einige Erfahrung im Umgang mit GEM (nicht in der Programmierung desselben) und vor allem mit einem Resource-Construction-Set vorhanden sein. Es hilft wenig, wenn Sie GEM zwar dem Namen nach kennen, aber nicht wissen, was für eine Vielfalt hierin steckt. Sind diese Voraussetzungen erfüllt, sollten Sie zunächst mit einem Resource-Construction-Set (kurz RCS) ein Pull-Down-Menü entwerfen. Über die Programmierung brauchen Sie sich den Kopf jetzt noch nicht zu zerbrechen. Blutigen Anfängern im Bereich GEM sei vor dem Arbeiten mit GUP zunächst ein Buch über das “bedienerfreundliche Juwel” empfohlen, mit dem man sich in die Arbeitsweise der einzelnen Objektbäume und Schalter (Selectable, Radio. Touchexit etc.) einarbeiten kann, da sonst sicherlich nur “Frust” entstehen würde.
In den Programmen, die Sie im Interpreter benutzen, müssen Sie den Namen der Resource-Datei beim Aufruf von @init_gem eintragen. Nachdem Sie jedoch Ihren Quelltext compiliert haben, kümmert sich GUP selbständig um die *.RSC-Datei. GUP erkennt den Namen des Programmes direkt beim Programmstart (z.B. TEST.PRG) und sucht daraufhin nach dem dazugehörigen Resource-Code (hier: TEST.RSC) im gleichen Ordner. Das bedeutet für den Benutzer, daß er das Programm von jedem beliebigen Laufwerk und Ordner starten kann, da GUP automatisch im gleichen Ordner nach der *.RSC-Datei sucht.
Haben Sie Ihr Menü fertiggestellt und abgespeichert, schreiben Sie sich zunächst die Länge der *.RSC-Datei auf und laden im GFA-BASIC-Editor die auf der Diskette enthaltene “GUP"-Datei. Durch “MERGE" füllen Sie nun die PROCEDURE init_hnumbers mit der *.H(bzw. *.LST)-Datei Ihres Pull-Down-Menüs auf, das das RCS für Sie erstellt hat. Danach tragen Sie die Länge der *.RSC-Datei noch beim @init_gem-Aufruf am Programmanfang ein, und das war's dann (fast). Nun fehlen nur noch die Reaktionen auf die einzelnen Menü-Einträge (zum Beispiel Programmende bei "Quit"), die aber mit GEM-Programmierung an und für sich nichts zu tun haben. Diese werden in der PROCEDURE menu_function eingetragen, und fertig ist das Menü samt aller Verwaltungsaufgaben.
Ganz so einfach ist es in GFA-BASIC 2.x und 3.x nicht. Das Einlesen der DATA-Zeilen usw. entfällt. Stattdessen nimmt Ihnen das GUP in Verbindung mit einem RCS fast die gesamte Arbeit ab. Und programmiererfreundlicher ist es außerdem: Denn fügen Sie nachträglich einen weiteren Eintrag in die Menüleisten ein, so muß nicht der gesamte GFA-Quelltext umgeschrieben werden, da alle Einträge ihre alten Nummern bzw. Namen beibehalten. Sie müssen also nur in der PROCEDURE menujunction Ihren neuen Eintrag zusätzlich abfragen und die PROCEDURE init_hnumbers mit der neuen *.H-Datei einspeisen.
Zugunsten der Flexibilität sollte bei der Benutzung von Objektbäumen deren Name (Variablen benutzen!) verwandt werden und nicht deren Nummer. So läßt sich selbst bei größeren Änderungen an der RSC-Datei das Programm mit minimalem Aufwand anpassen, indem in der Prozedur init_hnumbers die Variablenzuweisungen abgeändert werden. Ein kleines Beispiel, wie einfach die Pull-Down-Menü-Verwaltung ist, zeigt Listing 1. Das entsprechende Menü finden Sie in Bild 1.
Etwas komplizierter sieht es aus bei der Benutzung und Verwaltung von Dialogboxen. Dies liegt jedoch nicht am GUP, sondern an der Vielfalt der Möglichkeiten. die eine Dialogbox dem Benutzer bietet. Schließlich besteht ja nicht jede Box nur aus Strings und einem Button, wie zum Beispiel eine Alertbox. Hier können neben mehreren Schaltern. Eingabe (Edit)-Feldern und Radiobuttons, ja auch Schieber (Slider), eventuell versteckte (Hidden) Objekte und vieles mehr vorhanden sein. Die beste Lösung zur Verwaltung aller Elemente liegt darin, Schritt für Schritt vorzugehen. Nach Möglichkeit sollten Sie zunächst immer nur ein Objekt in der Dialogbox herausgreifen und mit den GUP-Prozeduren verwalten. Funktioniert dies fehlerfrei, gehen Sie zum nächsten Element über usw., bis nacheinander alle Elemente Zusammenarbeiten.
Ein Beispiel für die problemlose Verwaltung einer Box mit drei Radiobuttons, einem Schalter, zwei Eingabefeldern und zwei Buttons sehen Sie ebenfalls in Listing 1. Die Dialogbox sehen Sie in Bild 2, die Objekttypen wurden mit kleiner Schrift gekennzeichnet.
Die Verwaltung von Fensterinhalten zählt ebenso zu den Aufgaben des GUP wie die Überwachung der einzelnen Fenstersymbole. In dem von GFA-Systemtechnik mitgelieferten Demonstrationsprogramm kann man wunderbar die Möglichkeiten nachvollziehen, die jedem Programmierer an die Hand gegeben werden. Die Erstellung einer Fensterverwaltung, wie sie zum Beispiel das Programm 1st_Word bietet, dürfte keinerlei Schwierigkeiten bereiten. Auch das Hin-und Her-Scrollen einer Grafikseite in einem Fenster ist für GUP eine Kleinigkeit. Die Zwischenspeicherung der Koordinaten eines Fensters vor seiner Vergrößerung auf volle Bildschirmgröße (Fenstersymbol oben rechts) erfolgt automatisch, so daß beim zweiten Anklicken des Symbols wieder die alte Fensterposition hergestellt wird.
In Bezug auf die weitere Fensterverwaltung sollte der Programmierer am besten einen Blick in das mitgelieferte Demo werfen, da eine Auflistung der Funktionen den Rahmen dieses Testberichtes sprengen würde.
Der Schlüssel zum eigenen Hintergrund nennt sich in der GEM-Sprache schlicht und einfach Desktop (übersetzt etwa: Schreibtischoberfläche). Bekannte Programme. die eigene Desktops verwenden, sind etwa Tempus, l1st_Word oder das Harddisk-Utility. Durch verschiedene grafische Symbole, sogenannte Icons, kann der Benutzer einzelne Aktionen durchführen, bei Tempus etwa einen im Speicher befindlichen Text ausdrucken, löschen oder ähnliches. Auch hier stellt das GEM-Utility-Package-Prozeduren zur Verfügung, die eine Desktop-Verwaltung zulassen. Mittels der Prozeduren change_desk oder switch_desk kann auf einen eigenen Hintergrund umgeschaltet werden.
Die Bewegung von Icons auf dem eigenen Hintergrund wird vom GUP ebenfalls verwaltet. Der Benutzer muß nur noch festlegen, welche Icons verschoben werden dürfen und welche nicht, und GUP zeichnet im Falle eines Falles die Ghost-Linie (gepunktete Linie, die die Icon-Form bei einer Bewegung darstellt) und überwacht die Bewegung. Ebenso verhält es sich mit dem Anklicken der Icons. Klickt der Benutzer auf eines dieser grafischen Elemente, erhält der Programmierer eine Nachricht, daß es angewählt wurde, und ihm wird ebenfalls mitgeteilt, ob es sich um einen Doppel- oder um einen Einfachklick handelte. Der Programmierer muß im RCS nur die maximale Länge des Icon-Textes (auch Banner genannt) festlegen und kann in seinem Programm die “Bildunterschrift" jederzeit verändern.
Zieht der Benutzer ein Symbol auf ein Fenster oder auf ein anderes Symbol, wird ebenfalls wieder eine Nachricht an den Programmierer übergeben. Eine einfachere Verwaltung eines GEM-Desktops gibt es wohl kaum.
In GFA-BASIC war es bisher schon kein Problem. Alertboxen erscheinen zu lassen. Nun ist es möglich, sie ebenfalls in eine *.RSC-Datei zu stecken und durch die GUP-Prozeduren form_alert oder edit_alert auf den Bildschirm zu bringen. Die Routine läßt es auch zu, Boxen mit variablen Texten anzuzeigen. Zusätzlich kann der Text einer Box im Objektbaum mehr als 30 Zeichen und vier Zeilen lang sein. Will man sich nicht auf drei Auswahlknöpfe beschränken und diese vielleicht noch untereinander anordnen, kann ja immer noch auf eine Dialogbox ausgewichen werden.
GUP verwendet zur Ausgabe von Texten eigene Funktionen. Selbstverständlich ist es “Gift", zum Beispiel mittels Print hier “dazwischenzufunken". Deshalb gibt es einige Befehle, die bei der Benutzung von GUP verboten sind. Dies bezieht sich natürlich nur auf die Routinen, die auf GUP zugreifen. Eine Übersicht über die verbotenen Befehle und die reservierten Variablen finden Sie in Tabelle I. Dennoch muß der Programmierer nicht auf alle Befehle verzichten, da ihm das GEM-Utility-Package hierfür “Ersatzprozeduren” zur Verfügung stellt. Den größten Verlust stellt sicherlich die verlorene Funktion Using (in Verbindung mit Print) dar. die sich im direkten Umgang mit dem GUP nicht mehr verwenden läßt. Außerhalb aller Dialogboxen. Menüs etc. lassen sich die “verbotenen Befehle” selbstverständlich weiterbenutzen.
Es hat viel zu lange gedauert, bis das Zusatzprogramm “GUP" auf den Markt gekommen ist. Dem Programmierer nimmt das GUP überall da die Arbeit ab, wo es irgendwie möglich ist. Einfacher läßt sich die Programmierung von GEM wohl nicht mehr durchführen, schließlich müssen nur noch die Benutzerprozeduren ausgefüllt und so den eigenen Bedürfnissen angepaßt werden. Den letzten Rest übernimmt dann das Resource-Construction-Set mit seinen Flags, das ja zum GFA-BASIC 3.0 mitgeliefert wird.
Negativ am GFA-GUP ist in erster Linie wohl das Verbot des Print- Befehles, was immerhin bedeutet, daß ein Print Using demnächst im Umgang mit dem GUP “ins Wasser fällt". Da wäre doch eine Quelltextprozedur sinnvoll, die einen String umwandeln kann, damit der Programmierer wenigstens mittels des Text Befehls seine Ausgaben “geUSINGt” durchführen kann. Vielleicht trägt GFA ja demnächst noch dazu bei, dieses “kleine" Manko abzuschaffen, sei es durch eine Quelltextprozedur oder durch Using als Funktion.
Wenn man bedenkt, daß Interpreter und Compiler zusammen nur 198,- Mark kosten, erscheinen 149,- Mark für das GEM-Utility-Package in Bezug auf das Leistungsangebot nicht ganz angemessen. OMIKRON.Soft wäre hat sich schließlich auch auf einem vernünftigen Preislevel eingependelt. Ein Preis von DM 99,- würde sicher für eine höhere Verbreitung des GUP sorgen, was dem Programm nur zu wünschen wäre. Schließlich trägt es zu einer Verbesserung der Software-Qualität auf dem ATARI ST wesentlich bei und sollte von jedem GFA-BASIC-Programmierer benutzt werden.
RP
Bezugsadresse:
GFA-Systemtechnik GmbH Heerdter Sandberg 30-32 4000 Düsseldorf 11
Verbotene Befehle
CLEARW
CLOSEW
FULLW
INFOW
INPUT
MENU
MENU OFF
MOUSEK
MOUSEX
MOUSEY
OPENW
PRINT
TITLEW
Reservierte Variablen
Alertbutton
Calling file$
Desk
Deskaddr
Exitbutton
Mcode$
Mentitle
Menuaddr
Menunr
Nhandles
Tree
Treeaddr
Window
Tabelle 1: Vom GEM-Utility-Package reservierte Variablen und im Umgang damit verbotene Befehle.