Das ATOS-Magazin 2/98
ATOS Programmierpraxis
GEMScript (nicht nur) aus Programmierersicht
Es gibt prinzipiell keine Vorschriften die Kommandos betreffend. Alles ist hier erlaubt, so auch das Einführen neuer Messages - was sinnvoll ist, denn man kann natürlich nicht für jede mögliche Anwendung von vornherein fest definierte Kommandos festlegen - was für eine Textverarbeitung gut ist, muß in einem Grafikkonverter noch lange nicht sinnvoll sein.
Dennoch gibt es einige standardisierte Kommandos, die wohl von den meisten GEM-Applikationen unterstützt werden und deren Aufbau und Parameter im großen und ganzen überall gleich sein sollten:
Wie man sieht, sind dies überwiegend Kommandos, wie man sie aus GEM-Menüzeilen aus den Menüs Datei und Bearbeiten kennt. Das Vorgehen der einzelnen Programme ist hierbei relativ einheitlich, so daß Standardmessages in diesem Fall sinnvoll sind.
Das Kommando Open z.B. dient zum Öffnen von Dateien und ist folgendermaßen spezifiziert:
Kommando: Open
Parameter: Datei+Pfad (optional)
Also würde die entsprechende Kommandozeile, die eine Applikation dazu bringt, eine Datei namens "blafasel.txt" zu öffnen, folgendermaßen aussehen:
"Open\0blafasel.txt"
Nun könnten z.B. auch mehrere Dateien angegeben werden, wenn die angesprochene Applikation multiples Laden unterstützt:
"Open\0blafasel.txt\0laber.txt\0text.bla"
Diese Kommandozeile würde also die drei Dateien blafasel.txt, laber.txt und text.bla öffnen.
Ist nun z.B. ein Open-Kommando bei einer Applikation angekommen, muß dessen Empfänger wie auf alle GS_COMMAND-Messages mit einer GS_ACK-Message antworten, mit der dann ein Rückgabewert geschickt wird, der eventuell einen Fehler anzeigt.
Im nächsten Teil unseres Artikels werden wir näher auf den Message- und Kommandoaufbau einzelner Kommandos und die Implementation in eigene Programme eingehen.