GEM Easy - Easy GEM

Mit der EasvGEM-Librarv von OMIKRON ist es jetzt jedem OMIKRON.BASIC 3.0-Besitzer möglich, einfach und schnell Programme mit GEM-Unterstützung zu schreiben. Dazu muß man sich mit GEM nicht einmal auskennen: Die EasyGEM-Library unterstützt den Programmierer und entlastet ihn bei Menüzeilen, Dialogboxen und vor allem Fenstern so, daß er sich wirklich nur noch um die eigentliche Programmierung kümmern muß.

Obwohl EasyGEM eigentlich für den GEM-Laien gedacht (und geeignet!) ist, kann auch der erfahrene Programmierer sehr oft darauf zurückgreifen. Wer nicht gerade extreme Sonderwünsche hat, wird die AES-Aufrufe der normalen GEM-Library nicht mehr benötigen; wer sie trotzdem braucht - sie sind komplett unter EasyGEM verfügbar, denn EasyGEM enthält die normale GEM-Library. Keine Unterstützung bietet EasyGEM in punkto VDI. was aber auch gar nicht nötig ist, da ja über OMIKRON.BASIC fast alle VDI-Aufrufe auf einfachem Wege zugänglich sind.

Damit Sie gleich richtig eingestimmt werden, die “schlechte Nachricht*’ vorweg. Natürlich wird GEM durch EasyGEM nicht schneller, allerdings auch kaum merkbar langsamer. Doch der Komfort, der zur Verfügung steht, ist beträchtlich - und das bei einer traumhaft einfachen Bedienung! Die Nachteile sind klar: Erstens wird Ihr Programm bestimmt nicht kürzer; zweitens können Sie über EasyGEM nicht alles machen, was über GEM geht (aber GEM und EasyGEM schließen sich ja nicht aus).

Beides ist ein geringer Preis für die Einfachheit des Programmentwurfs. Keine Überlegungen der Art: “Ach, wie war das bloß? Was liefert Evnt Multi in Int-out%(5) zurück?” behindern den Ideenfluß, wodurch die Programmierzeiten verkürzt und die Fehlerquellen erheblich reduziert werden. So kommt es, daß auch ich, als Programmierer in und Erforscher des GEM, versiert wie ich mir einbilde, auch gerne auf dieses Werkzeug zurückgreife. Was leider nur meine Faulheit beweist...

Das Beste zuerst: Die Menu-Library

Mit EasyGEM braucht man für eine normale Menüzeile kein einziges Resource Construction Set (RCS) mehr, solange man auf solchen Luxus wie Icons, Grafikbilder oder Grafikobjekte (Buttons und Boxen) im Menü verzichtet. Man schreibt einfach ins Programm, wie die Menüzeile auszusehen hat (siehe Listing 1).

Die Definition ist ganz einfach: Make_Menu leitet die Definition ein, M_Title und Menu_Entry legen die Titel und Einträge fest, und End_Menu sorgt dann für das endgültige Anlegen der Objektstruktur für die Menüzeile. Selbstverständlich können während der Menüdefinition auch beliebige BASIC-Befehle ausgeführt werden, so daß man auch per Bedingung (!) Einträge oder gar Titel aus der Menüzeile weglassen oder anders präsentieren kann. Anstatt also zwei fast gleiche Menüzeilen für Färb- und Monochromversion eines Zeichenprogrammes zu entwerfen und zu definieren, wählt man an betreffender Stelle einfach per IF eine der beiden möglichen Einträge. Oder: Bei Vorhandensein eines Blitters wird ein zusätzlicher Menüeintrag eingefügt, der die Option zum Ein- und Ausschalten desselben zur Verfügung stellt; ist kein Blitter vorhanden, kann man auf diesen Eintrag ganz und gar verzichten.

Nach der Definition kann man die Menüzeile natürlich verwenden (sonst hätte man das Ganze ja lassen können). Man veranlaßt die Darstellung derselben durch M_Show, wartet auf das Anklicken eines Eintrags per M_Waitmesag (bzw. fragt mit Easy_Mesag nach, ob gerade angeklickt wurde, ohne darauf zu warten). Dann tut man das Entsprechende, und wenn man fertig ist, läßt man das Menü wieder unter den Tisch fallen mit M_Hide.

MakeMenu " Acc ","  Info ",Info_Eintrag
M_Title "  Nix drin "
M_Entry "  Do is nix ",Nix
M_Line_Entry
M_Entry "  Do a net ",Nix2
M_Title "  Fine "
M_Entry "  End* ", Allaa Am
End_Menu

Listing 1: Menü-Zeilen ganz einfach konstruiert

Um zu erkennen, welcher Eintrag angeklickt wurde, geben alle Aufrufe in der Menüdefinition eine Zahl zurück (deshalb auch der letzte Parameter), deren genauer Wert gar nicht interessiert. Man muß die verwendete Variable einfach mit der Nummer von M_Waitmesag oder Easy_Mesag vergleichen und dann eine entsprechende Aktion starten. Diese Art der Menü-Abfrage ist - bei sinnvoller Wahl der Variablennamen - selbstdokumentierend und deshalb auch sehr leicht zu lesen. Listing 2 zeigt: Die ganze Menü-Verwaltung ist wirklich so leicht.

Das kannste abhaken - Attribute

Die Verwendung von Attributen ist genauso einfach. Ein einfacher Aufruf, und ein Menüeintrag ist nicht mehr anwählbar (hell gemustert). Ein anderer, und er hat ein Häkchen davor. Für jedes Attribut (disabled, crossed, checked) gibt es einen getrennten Aufruf zum An- und zum Ausschalten; ebenso zum Abfragen, ob dieses Attribut gesetzt ist. Alle Attribute lassen sich auch sehr einfach während der Definition angeben, wobei es zwei Möglichkeiten gibt: mit besonderen Aufrufen, wie M Disabled Entry, oder indem man einfach nach dem betreffenden M Entry das Attribut mit der entsprechenden Prozedur setzt, hier also M Disable. Zusätzlich gibt es bei der Definition einen Extraaufruf für die nichtselektierbare gestrichelte Trennlinie zwischen Menüeinträgen (M Line Entry, in Listing 1 verwendet).

Sonstige Nettigkeiten und mehrere Menüs

Neben der Änderung der Attribute ist auch noch die Abänderung des Textes der Einträge möglich (wie im GEM auch), solange man die vorige Länge des Menüeintrages nicht überschreitet. Übrigens kann man auch den momentanen Text jedes Eintrags über eine Funktion auslesen.

Wer nicht auf das vorige Menü Rücksicht nehmen will, der kann sich genauso einfach ein zusätzliches Menü (oder mehrere davon) vordefinieren und dann ruck zuck! "die Fronten wechseln”, sprich: eine andere Menü-Zeile einblenden. Der Mehraufwand hierfür ist denkbar klein, denn die Verwaltung, welche Menüzeile im Moment aktiv ist, wird über eine interne Nummer gemanagt; diese erhält man in einer Variablen zurück, so daß man sich mit einem einzigen IF helfen kann, wie Listing 3 zeigt.

Die Funktion FN M_Which gibt die Nummer des gerade aktiven Menüs zurück, so daß man sich beim Umschalten der Menüs nicht einmal das aktuelle Menü zu merken braucht. Diese Nummer braucht man allerdings bei jeder Abfrage,

ob ein spezieller Eintrag angeklickt wurde, da EasyGEM die gleiche Objektnummer in verschiedenen Menüs belegt. Deshalb das zweifache IF in Listing 3. Daß diese zusätzliche Abfrage nötig ist, ist nicht weiter schlimm, da man sie sowieso - aus Gründen der Selbstdokumentation und des besseren Stils - verwenden würde, auch wenn sie redundant wäre. Das Programm ist dadurch einfacher zu warten.

Der Dialog mit dem Bürger

Auch für Dialogboxen benötigte man bis jetzt immer ein RCS. Mit EasyGEM ist dies weitgehend Vergangenheit. Obwohl das Dialogboxkonzept nicht ganz so gut gelungen ist wie die Menüverwaltung, stellt EasyGEM doch eine große Hilfe dar. Natürlich gibt es auch hier wieder Einschränkungen. Für den Normalfall ist vorgesorgt, aber Icons und Bilder lassen sich auch hier nicht in den Objektbaum einbinden, und es gibt keine Touchexit-Objekte.

LIBRARY Easygem ,"\easygem.lib" 
Easy_Init
' Hier kämen die Definitionen aus Abb. 1 
M_Show
REPEAT
PRINT @(0,32);
	M_Waitmesag Eintrag' wartet auf das Anklicken eines Menü-Eintrags 
	IF Eintrag=Info_Eintrag THEN PRINT "Info? Nee?"
	IF Eintrag=Nix OR Eintrag=Nix2 THEN PRINT "Det war wohl nischt!"
UNTIL Eintrag-Alles_Aus
Easy_Exit	' M_Hide wird in Easy_Exit sowieso aufgerufen

Listing 2: Das Erkennen des angeklickten Eintrags

Das Erstellen einer Dialogbox ist dem Definieren von Menüzeilen ähnlich. Man leitet die Definition ein (Make -Dialog), gibt die Objekte in Form von Prozeduraufrufen an (z.B. D Title, siehe unten) und beendet das Ganze mit End Dialog. Die Dialogbox (d.h. deren gesamter Objektbaum) wird bei End Dialog in einen anzugebenden String gepackt, der dann logischerweise nicht mehr direkt geändert werden darf. Wurde der String versehentlich wesentlich verändert, erkennt EasyGEM dies und gibt eine entsprechende Fehlermeldung aus; bei geringfügigen Änderungen allerdings hat EasyGEM keine Chance, so daß Abstürze bei Easy Dialog die Folge sein können, da ja die Objektstruktur zerstört sein kann. Wie gesagt - die Gefahr liegt bei GEM; den String darf man auf keinen Fall von Hand ändern, es sei denn, man ersetzt ihn vollständig durch eine andere Objektdefinition.

Easy_Init

Make_Menu "  Desk ","  2. Menü ",To_Menu_2 
M_Title " 1 "
	M_Entry " 11 ",Elf
	M_Entry " 12 ",Zwoelf 
M_Title " 2 "
	M_Entry " 21 ",Zwei_Eins
	M_Entry " 22 ",Zwei_Zwei 
M_Title " 3 "
	M_Entry " 31 ",Drei_Eins
	M_Entry " 32 ",Drei_Zwei 
M_Title "Ende"
M_Entry "Ende",Ende 
End_Menu Menu1

Make_Menu "  Desk ","  1. Menü ",To_Menu_1
M_Title "  A  "
	M_Entry " A1 ",A_Eins
	M_Entry " A2 ",A_Zwei 
M_Title "  B  "
	M_Entry " B1 ",B_Eins
	M_Entry " B2 ",B_Zwei 
M_Title " C "
	M_Entry " C1 ",C_Eins
	M_Entry " C2 ",C_Zwei 
End_Menu Menu2

M_Show Menu1 
REPEAT
	M_Maitmesag Eintrag 
	Akt_Menu=FN M_Which
	IF Akt_Menu=Menu1 THEN
		IF Eintrag=Elf THEN REM ... 
		'...
		IF Eintrag=To_Menu_2 THEN M_Show Menu2
		'...
	ENDIF
	IF Akt_Menu=Menu2 THEN
		IF Eintrag=A_Eins THEN REM ... 
		'...
		IF Eintrag=To_Menu_1 THEN M_Show Menu1
		'...
	ENDIF
UNTIL Eintrag=Ende 
Easy_Exit

Listing 3: Mehrgängiges Menü für Feinschmecker

Dies ist übrigens der einzige Fall, an dem die EasyGEM-Library einen Schwachpunkt aufweist - ansonsten sind Absturzstellen so gut wie möglich “abgeriegelt". Diese Absicherung ist bei GEM sehr (!!!) wichtig, denn es ist sehr übellaunig und verzeiht selten einen Absturz. Und der kann bei normalem Umgang mit GEM (ohne EasyGEM) - erst recht beim Testen - sehr leicht auftreten. wenn man nicht verteufelt gut aufpaßt.

Die Definition der Dialogbox ist etwas ungewöhnlich (im Vergleich mit der Definition eines Menüs). Man gibt nämlich bei jedem Aufruf (also pro Objekt) eine Zeilenummer mit an, die relativ zum oberen Rand der Dialogbox gezählt wird. Auf jede Zeile kann nur ein einziger Aufruf angewandt werden, um diese zu definieren; die Zeilennummer ist an sich also wert- und sinnlos. Sie wird aber von einigen anderen Aufrufen benutzt (s.u.).

Als Objekte können in der Dialogbox verwendet werden:

Titel: fett umrahmte, zentrierte Box mit zentrierter Schrift und Schatten schräg nach rechts unten
Button: normale beschriftete Box, die unabhängig von allen anderen an-klickbar ist
Radiobutton: Button, der bei einer Auswahl von mehreren Buttons exklusiv aktiviert werden kann (wie UKW - KW- MW bei Radios, daher auch der Name)
Exitbutton: ein Button, der angeklickt den Dialog beendet
nichtedierbarer, feststehender Text: für Sachen, die sich nie ändern
nichtedierbarer, aber im Programm änderbarer Text: für Informationen wie verfügbarer Speicherplatz, max. Anzahl von Dateien oder so ähnlich
edierbarer Text für alle veränderbaren Daten: es können entweder nur Ziffern oder grundsätzlich alle Zeichen eingegeben werden.

Bei allen Arten von Buttons können normaler Text und Buttons gemischt werden; zur Unterscheidung dient die gleiche Syntax wie bei einer Alertbox - also Buttons in rechteckigen Klammem, der Rest ist Text. Für die weitere Verwendung werden die Buttons und Textstücke durchgezählt; diesen Index braucht man dann zum Setzen und Abfragen des Status’ der Buttons.

Radiobuttons können nur in der gleichen Zeile gesetzt werden. Eine andere Zeile heißt gleichzeitig auch andere Radiobuttons, d.h. jede Zeile ist getrennt von der anderen.

Eine Mischung verschiedener Buttonarten in einer Zeile ist nicht möglich. Dies ist der Preis, den man für die einfache Definition zahlen muß.

Eigentlich ist die Definition einer Dialogbox schon das Komplizierteste an der Dialogverwaltung des EasyGEM. Um den Dialog zu beginnen, muß lediglich der Aufruf Easy_Dialog abgearbeitet werden. Die Übergabe von Text oder Status der Buttons erfolgt sowohl als Aus- als auch als Eingabe über zwei Felder namens Dialog_Button%F (für normale, Exit- und Radiobuttons) und Dialog_Text$ (für Texte). Vor Easy_Dialog setzt man also die entsprechenden Feldelemente, um einen Grundzustand zu erreichen, und nach Easy_Dialog liest man die Informationen entsprechend heraus. Als Index wird immer die relative Zeilennummer von der Dialogboxdefinition benötigt.

Bei Radiobuttons kann man eine spezielle Funktion FN Rbutton aufrufen, die direkt die Nummer des aktiven Radiobuttons -oder Null - zurückgibt. In der Praxis sieht die Dialoggeschichte dann so aus (siehe Listing 4).

LIBRARY Easygem ,"\EasyGEM.LIB" 
Easy_Init
Make_Dialog Box$,Box1 
		D_Title 2,"  Suchen "
		D_Input 4," Suchen nach:",32,Di_Text
	D_Radiobutton 6,"Suchen ab [Anfang] [Cursor] [Ende]"
		D_Title 9," Ersetzen "
		D_Input 11," Ersetzen :",32,Di_Text
	D_Radiobutton 13,"[Alles][Einmal][Alles mit Rückfrage] ersetzen"
		D_Exitbutton 16,"      Wahl [Ok] oder [Abbruch] ?",0
		D_Empty 19
End_Dialog Box$,Box1

'Initialisierung
Clear_Parameter Box1' ware eigentlich nicht nötig 
Dialog_Button%F(6,4,Box1)=1' Cursor-Button vorselektieren

'Dialogbox anzeigen und Dialog starten 
Easy_Dialog Box$,Box1,Exit_Button 
Easy_Exit

'Auswertung
PRINT "Suchen nach “;Dialog_Text$(4,Box1) 
PRINT "Gesucht wird ab ";
Rbut=FN Rbutton(6,Box1)
IF Rbut=2 THEN PRINT "Anfang"
IF Rbut=4 THEN PRINT "Cursor"
IF Rbut=6 THEN PRINT "Ende"
PRINT
Rbut=FN Rbutton(13,Box1)
PRINT "Ersetzen durch ";Dialog_TextS (11,Box1) 
PRINT "Ersetzt wird ";
IF Rbut=0 THEN PRINT "nichts"
IF Rbut=1 THEN PRINT "alles"
IF Rbut=2 THEN PRINT "einmalig" 
IF Rbut=3 THEN PRINT "mit Rückfrage" 
IF Exit_Button=2 THEN
	PRINT "Suchen und Ersetzen wurde gestartet" 
ELSE PRINT "Abbruch"
ENDIF

Listing 4: So führt man einen Dialog

Übrigens: Für kompliziertere Anwendungen kann anstatt des Easy_Dialog-Aufrufs dessen Funktion durch vier einzelne Aufrufe ersetzt werden, die Teilaktionen ausführen:

Sperren von Bildschirmaktionen per Wind_Update und gleichzeitig Anzeigen der Box
erneutes Zeichnen
Dialogeingabe ohne Neuzeichnen
Schließen der Dialogbox und Wiedererlauben von Bildschirmaktionen.

Durch diese Zerlegung können zeitkritische Anwendungen auch in Dialogboxen stattfinden (Anzeige von Daten während der Formatierung von Disketten, Speichertest, Drucker-Spooling oder ähnliches). Und somit ist die Dialogbox-Library tatsächlich auch für Profis interessant.

Fensterln ohne Leiter: Die Window-Library

Sehr stark vereinfacht wird der Umgang mit Fenstern, da man EasyGEM nur noch sagen muß: “So sähe das Fenster aus, wenn alle Daten dargestellt werden würden”, und der Rest vollautomatisch weiterläuft. Das heißt. Sie bestimmen Art, sichtbaren Ausschnitt, Größe und Position des Fensters einmal im Programm und überlassen die Reaktion auf den Benutzer voll der Library.

Dabei wird ein besonderes, aber naheliegendes Konzept herangezogen - ein Fenster wird als kleiner Ausschnitt eines großen Universums (oder so ähnlich) betrachtet. Man hat also irgendetwas Großes, und legt darüber ein Fenster, durch das man eben nur einen kleinen Teil sieht: dieses Fenster kann innerhalb des Großen herumgeschoben werden. Ohne EasyGEM würde man es natürlich ähnlich machen; mit EasyGEM ist es aber noch sinnvoller, denn man übergibt der Library den kompletten Bildinhalt (Text oder Grafik) und vergißt, wie gesagt, den Rest. Dazu muß es natürlich Routinen geben, mit denen man die Fensterposition auf dem Bildschirm, die Position relativ zum Ganzen und die Fenstergröße setzen und wieder abfragen kann.

LIBRARY Easygem ,"\EasyGEM.LIB" 
Easy_Init

Desktop=-l
Win_Getwork Desktop,X,Y,W,H' Desktop-Größe ermitteln 
Twin_Open T1,X,Y,W,H,160,20,"Text"' und hier einsetzen 
Easy_Mesag 0,Buf$
Win_Domessages Buf$' 1. Redraw erkennen und ausführen
REM Der virtuelle Bildschirm ist jetzt 160 x 20 Zeichen groß.
REM Davon wird nur das auf dem Bildschirm angezeigt, was draufpaßt.

Twin_Print T1,"Bitte geben Sie etwas ein:" 
Twin_Input T1,"","ä%0”,160
REPEAT
	Easy_Mesag 0,Buf$
	Win_Domessages Buf$,"NO_CLOSING"
UNTIL FN Twin_Input(T1) OR FN Win_Closed(T1) 
Twin_Print T1%L,"(Schließfeld anklicken)"
IF FN Win_Closed(T1)=0 THEN
	Twin_Print T1
	Twin_Print T1,"Ihre Eingabe war:" 
	Twin_Print T1,FN Twin_Input$(T1) 
	REPEAT
		Easy_Mesag 0,Buf$
		Win_Domessages Buf$ 
	UNTIL FN Win_Closed(T1)
ENDIF

Easy_Exit
END 
-No_Closing
Easy_Alert(1,"[1](Zuerst RETURN drücken]! Gebongt ]",B) 
RETURN

Listing 5: Fenster unter EasyGEM

Um arbeiten zu können, muß EasyGEM wissen, um was für ein Fenster es sich handelt, besser gesagt, was drin steht. Die Library unterscheidet Text-, Grafik- und User- (oder Vielfachanwendungs-) Fenster.

Für die Textfenster kann logischerweise am meisten Unterstützung geboten werden: Zeilenweise Eingabe (auch INPUT USING-ähnlich!), Textänderungen mit sofortiger Darstellung oder versteckt, automatische Reaktion auf Scrolling und auf das Ändern der Fensterausmaße oder -position (siehe Listing 5).

Für Grafikfenster gibt es einen Aufruf namens Gwin_Activate. Damit werden alle Grafikbefehle (und VDI-Aufrufe der GEMLib) in das Grafikfenster umgeleitet. Nach Gwin_Activate kann man also ganz normal Zeichnungen erstellen, als hätte man nur den Bildschirm ohne Fenster. Bei Grafikfenstern hat EasyGEM dann “nur” die Aufgabe, den sichtbaren Teil des ganzen Bildes in den Fensterbereich zu bringen. Selbstredend reagiert die Library auch hier auf das Anklicken von Scrollpfeilen und Scrollbalken selbst. Hat man genug in das Bild gezeichnet, kann man die Umleitung wieder aufheben. so daß alle Grafikbefehle wieder auf dem normalen Bildschirm ausgeben.

Die letzte Fensterart, Userwindows, stellt die am wenigsten unterstützte Form dar. Hier muß eine eigene Redraw-Routine angegeben werden, die selbst für den richtigen Inhalt des Fensters sorgt. EasyGEM erspart einem dann nur das Ermitteln der Rechteckliste und das Clipping für das betreffende Rechteck: an die Benutzer-Redraw-Routine werden die Fensterkennziffer, die Bildschirmkoordinaten und Ausmaße des Rechtecks und die Koordinaten auf dem realen Bildschirm übergeben. Der Rest (Scrolling, Zeichnen, Darstellen des sichtbaren Ausschnittes usw.) ist Sache des Programms.

Bei allen Fensterarten wird der Fensterinhalt bei Bedarf automatisch neu gezeichnet (bzw. das Neuzeichnen an die eigene Routine weitergeleitet); dieser Vorgang kann aber auch gesondert per EasyGEM-Aufruf ausgelöst werden (z.B. wenn man erst einen Bildschirm komplett aufbauen will, bevor man ihn anzeigen läßt). Für die automatische Restaurierung muß man lediglich die von Easy_Mesag (mit zwei Parametern) erhaltene Meldung an Win_Domessages weitergeben. Leider tritt bei Userfenstern noch eine “Unschönheit” auf; beim Eröffnen des Fensters wird nämlich zweimal der Redraw-Vorgang ausgelöst - ein echter Fehler der Library (aber nur eine “Unschönheit”).

Wandeln auf fremden (Datei-)Pfaden: Fileselect-Library

Einen nur geringen Teil (der Dokumentation) in der EasyGEM-Library machen die Hilfen für die Fileselectorbox aus. Nichtsdestotrotz sind “die paar Aufrufe” sehr nützlich beim Umgang mit Dateipfaden und Laufwerken.

Es gibt eine vereinfacht bedienbare Fileselectorbox mit Titel (das ist allerdings kein Verdienst von EasyGEM, sondern wird bereits von der GEMLib 3.0 unterstützt bzw. simuliert, wenn man kein TOS 1.4 besitzt). Der Titel ist sehr nützlich, denn jetzt sagt das Dateiauswahlfenster selbst, worum es eigentlich geht, und warum man jetzt eine Datei auswählen soll (z.B. “LOAD ASCII”,”DELETE File”), was u.U. sehr wichtig sein kann.

Worin liegt aber nun die Vereinfachung? Nun, der Index (das ist die obere der beiden Zeilen in der Fileselectorbox) wird immer mit dem vollständigen Pfad inklusive Laufwerk ergänzt. Der Dateiname (“Auswahl" in FSEL_INPUT) kann einen (unvollständigen) Pfad enthalten; dann wird der Index entsprechend manipuliert. Und bei Beendigung der Box steht im Auswahlstring immer der vollständige Pfad inklusive angewählter Datei (oder nichts, wenn keine Datei ausgewählt und “Abbruch“ angeklickt wurde).

Doch das ist nicht alles. Nicht nur der Programmierer kann die Fileselectorbox vereinfacht an wenden, sondern auch der “Dialogpartner“. Er kann bei Auswahl nichts eingeben und RETURN drücken (oder auf OK klicken) - dann wird der Pfad im Index als Standardpfad eingestellt. Man kann in der Auswahl auch nur ein Laufwerk angeben (z.B. “C:“), dann wird nach dem Verlassen der Box der Pfad auf das entsprechende Laufwerk umgestellt. Beides Mal wird die Fileselectorbox erneut aufgerufen, genau wie man das vom BASIC-Editor der Version 3.0 auch schon gewohnt ist.

Neben dieser “Kleinigkeit” gibt es noch Funktionsaufrufe, die aus einem String den Pfadnamen oder den Dateinamen isolieren oder die Extension des Dateinamens durch eine andere ersetzen. Man kann eine Datei automatisch in allen möglichen und unmöglichen Pfaden suchen lassen (angegebener Pfad, dessen übergeordneter Pfad, Hauptverzeichnis des aktuellen Laufwerks und der Laufwerke A:, C: bis Pr, Standardpfad des Environment-Strings; gesucht wird allerdings in sinnvoller Reihenfolge!). Außerdem kann man sich einen Pfad zusammenbauen lassen (z.B. aus dem Leerstring den aktuellen Pfad, aus dem Laufwerksbezeichner den Pfad dieses Laufwerks usw.). Und für compilierte Programme gibt es noch eine Besonderheit: eine Fileselectorbox (wie oben), die den sogenannten Command Tail (Angabe bei “.TTP“-Programmen) als Index verwendet. Wurde im Command Tail ein vollständiger Dateiname gefunden, wird die Box unterdrückt, denn eine Wahl hat dann ja schon stattgefunden.

Eigene Fehler sind die besten

Die EasyGEM-Library verfügt sogar über ein eigenes Fehlermeldungssystem, das unabhängig ist vom BASIC-Fehlersystem und von ON ERROR GOTO, sich aber ähnlich (per eigener Fehlerroutine) abfangen läßt. Der Vorteil ist klar; ON ERROR GOTO bleibt frei für das Programm, und trotzdem braucht man auf die EasyGEM-Fehlermeldungen nicht zu verzichten. EasyGEM bemerkt und mokiert viele Bedienungsfehler, die auch klar und deutlich in der Meldung angezeigt werden. Der oder die Fehler sind also leicht anhand der Fehlertexte zu finden. Abfangen lassen sie sich - wie gesagt über einen ON ERROR ähnlichen Aufruf. Da ON ERROR allerdings nur simuliert wird, entstehen einige Einschränkungen (keine Rückkehr an die fehlerhafte Stelle möglich, keine Restaurierung von globalen Variablen, die Fehlerzeile ist nicht bekannt), die aber nicht gravierend sind. Alle Fehler können nur durch “Fehler” im Programm erzeugt werden, nicht jedoch durch falsche Bedienung von “außen”. Das komfortable Abfangen von Fehlermeldungen ist also nicht nötig.

Ein Bonbon: Bei Menü- und Dialogboxdefinition ist es möglich, einen Namen anzugeben, der dann in allen Fehlermeldungen betreffs Menüzeilen bzw. Dialogboxen auftaucht. Sehr nützlich ist dies bei Verwendung mehrerer Menüs, da man ansonsten nicht weiß, in welchem Menü nun der Fehler aufgetreten ist.

Komfort versus Geschwindigkeit?

Wie bereits gesagt - Programme werden bestimmt nicht schneller und auch nicht kürzer durch Verwendung der EasyGEM-Library. Sie werden aber erheblich schneller und sicherer entwickelt. Wer so auf Geschwindigkeit aus ist wie ich, der wird sowieso das Endprodukt compilieren; und dann geht die Post ab. Das Programm wird kürzer (der Compiler V3.04 kann nicht benötigte Library-Routinen den Hasen geben) und natürlich sehr viel schneller. Aber Wunder sollte man nicht erwarten - selbst mit EasyGEM ist man immer noch von der GEM-eigenen (gähn!) Geschwindigkeit abhängig.

Schlußrapport

Will man alles zusammenfassen, muß man wohl sagen: EasyGEM ist fast ohne Makel. Die Menü-Library ist ausgereift und wirklich für jeden anwendbar (mir fiel nur eine einzige Verbesserungsmöglichkeit auf). Dialogboxen kann man auch sehr gut und leicht verwenden, wenn auch das Konzept nicht ganz meinen Geschmack trifft und mit Sicherheit noch eine Kleinigkeit leichter gemacht werden kann (nämlich ohne Dialogboxzeilennummern). Die Fileselector-Library ist vollständig, die Fensterverwaltung gelungen - einfacher kann man es nicht haben. Und damit man all das anwenden kann, braucht man eine gute Dokumentation, die man bei EasyGEM auch bekommt. Das eng bedruckte Handbuch bietet auf seinen 68 Seiten auch dem GEM-Anfänger eine vollkommen ausreichende Anleitung zum Umgang mit EasyGEM. Für jede Teil-Library gibt es Demoprogramme auf der Diskette, die zur Betrachtung auch im Handbuch abgedruckt sind. Spätestens mit denen wird dann jeder Zweifel über die Verwendung von EasyGEM ausgeräumt.

Die EasyGEM-Library wird auf einer einseitigen Diskette, nicht kopiergeschützt. mit ausführlicher, gut lesbarer Anleitung geliefert. Die Library liegt im speziellen OMIKRON.BASIC-Library-Format vor und ist somit nicht auflistbar und nur ab BASIC V3.0 verwendbar. Die nicht gerade kurze Library (fast 72 KBytes im Programm) wird bei Verwendung eines Compilers ab V3.04 automatisch auf die unbedingt nötige Größe gebracht, was für den professionellen Einsatz ratsam ist. Übrigens muß keine Lizenzgebühr oder ähnliches für den Verkauf von Programmen mit EasyGEM entrichtet werden. Die Library ist für DM 79.- direkt bei OMIKRON und bei vielen Fachhändlern erhältlich.

Bezugsadresse

OMIKRON.Software Erlachstr. 15a 7534 Birkenfeld 2

Clemens Hoffmann

Aus: ST-Computer 03 / 1989, Seite 47

Links