Programme unter GEM Teil 1

Ein Programm unter der Benutzung von GEM zu schreiben, ist nicht allzu schwer. Der höhere Aufwand wird durch eine leicht zu bedienende Benutzeroberfläche entlohnt. Einige Grundlagen, die die Programmierung erleichtern, sollen hier erörtert werden. Ein wenig Kenntnis der GEM-Routinen und von deren Namensgebung sollte vorhanden sein, da nicht alle Routinen erklärt werden können. Trotzdem dürfte es nicht schwerfallen, den Erläuterungen zu folgen.

GEM steht - wie sicher die meisten wissen - für Graphics Environment Manager. Es handelt sich um eine Bedieneroberfläche, die geschaffen wurde, um den Umgang mit Computern zu erleichtern. GEM beinhaltet die beiden Funktionsblöcke AES -Applications Environment Services - und VDI - Virtual Device Interface -. Auf Wissen um das VDI soll hier nicht vertiefend eingegangen werden, uns liegt hier vielmehr die Gestaltung der Programme am Herzen.

Das AES - eigentlich "die" AES - stellt die für den Bediener wichtigen Elemente wie Fenster. Menüs und Dialoge zur Verfügung. Da das AES Graphik Routinen benötigt, steht es hierarchisch über dem VDI, d.h. es benötigt das VDI.

Grob verkürzt kann man sagen, daß das AES für das Programmhandling und das VDI für die Ein- und Ausgabe (von Graphik) zuständig ist.

GEM-Programme zeichnen sich dadurch aus, daß sie unabhängig vom Rechner sind. Sie sind also so zu halten, daß sie ohne weiteres auch auf anderen Rechnern lauffähig sind. Lediglich eine Übersetzung (Compilier-Vorgang) sollte erforderlich sein, um das Programm an neue Rechner anzupassen. Eine GEM-Programm-Portierung dürfte also in wenigen Minuten geschehen sein.

Hat man lange auf einem speziellen Rechner nicht portabel programmiert, könnten zu Beginn einige Schwierigkeiten auftauchen. Aber auf Rechnern wie dem COMMODORE 64 ist eine vom Rechner unabhängige Programmierung nicht vorgesehen, und daher stört es auch nicht sehr, wenn im Speicher herumgewühlt wird! Die Umgewöhnung lohnt sich aber auf jeden Fall! Fänden Sie es denn nicht auch schön, wenn sich alle Programme mit einer gewissen Einheitlichkeit (nicht Eintönigkeit!!) präsentierten und sofort bedienen ließen? Ärgert es Sie nicht auch, wenn Sie beispielsweise lange nach einer Möglichkeit suchen müssen, ein Programm beenden zu können?

Zur unabhängigen Programmierung gehört auf dem ST übrigens auch, daß die Line A-Routinen und Funktionen wie Getrez nicht benutzt werden. Getrez beispielsweise kann bei einem Ganzseiten-Monitor gar keine korrekten Werte liefern! GEM hingegen stellt Funktionen zur Verfügung, die es erlauben, den Arbeitsbereich korrekt zu ermitteln. Generell müssen rechnerspezifische Werte abgefragt und nicht angenommen werden. Es gibt nicht nur Monitore mit einer Breite von 640 und einer Höhe von 400 Pixeln. Auch liegt der Ursprung des Arbeitsbereichs nicht immer bei (0,0). Selbst die Buchstaben haben nicht immer eine Höhe von 16 Pixeln! Das AES und das VDI bieten reichlich Möglichkeiten, benötigte Werte abzufragen.

Aber welche Programmiersprache findet Verwendung? Eine passende Programmiersprache sollte einigen Kriterien genügen. Auf der einen Seite muß sie auch auf anderen Rechnern verfügbar sein, und auf der anderen Seite sollte man modularisieren können. Strukturierte Datentypen sind sehr hilfreich, da diese bei der Programmierung unter GEM immer wieder auftauchen. Ein Compiler darf auch nicht fehlen, da sonst einige Routinen nicht anwendbar sind. Man denke dabei nur an die für Accessories notwendige Funktion menu_register oder an die Funktion appl_find die auf den korrekten Namen des Programms angewiesen ist!

Es bieten sich also geradezu C, Modula-2 und Pascal an. Die Priorität liegt jedoch eindeutig bei C, denn diese Programmiersprache findet man am ehesten auch auf anderen Rechnern. Es kommen jedoch nur die Entwicklungssysteme in Frage, die sich an den gegebenen Standard halten. Wenn auf einem anderen Rechner unter einem anderen Betriebssystem erst alle Funktionen umbenannt werden müßten, so wäre die Programmierung nicht mehr rechnerunabhängig. Abstriche sind jedoch bei allen Routinen zu machen, die Betriebssystemfunktionen benötigen, GEM-Routinen gehören allerdings nicht dazu.

Ziel dieses zweiteiligen Artikels ist die Entwicklung eines Rahmenprogramms, welches zeigt, wie man ein Menü auf den Bildschirm bringt und verwaltet Parallel dazu werden Tastendrücke ausgewertet Auch das Desktop wird gegen ein neues ausgetauscht und das darauf befindliche Icon verwaltet. Da das Programm in C (Turbo C von Heimsoeth & Borland) geschrieben und sicher nicht jede Leserin/jeder Leser dieser Programmiersprache mächtig ist, soll zunächst eine Kurzfassung C-spezifischer Elemente gegeben werden.

C erfüllt alle oben gegebenen Anforderungen. Es handelt sich um ein Entwicklungssystem mit Compiler, die Modularisierung ist erlaubt, auch strukturierte Datentypen existieren.

Zur C-Syntax: Eine Voranstellung von ++ bzw. -- steht für die Inkrementierung bzw. Dekrementierung vor der Verwendung eines Variableninhalts. Folglich bedeutet ++x nichts anderes als x=x+1. Genauer: Steht in C Proc:(++x);, so bedeutet das beispielsweise in Pascal: x:=x+1; Proc(x); Steht das ++ bzw. — nach der Variablen, wird diese erst nach der Benutzung verändert, also wurde statt Proi'(x); x:=x +/; in C nur Proc(x++); geschrieben.

Die Symbole +, -, * und / stehen wie in anderen Programmiersprachen für die vier Grundrechenarten.

Steht das * direkt vor einem Vanablennamen - etwa *a -, bedeutet das, daß a auf einen Wert zeigt Dies entspricht dem A in Pascal Die Adresse einer Variablen kann man über den Adreß-Operator & ermitteln Wird der Adreß-Operator zur Übergabe von Parametern an die Routinen benutzt. kann der Inhalt der Variablen von der entsprechenden Routine verändert werden.

Die Operatoren >> und << bedeuten, daß um eine bestimmte Anzahl Bits nach rechts oder links verschoben wird. Eine bit weise Verknüpfung und wird mit &, eine bitweise Verknüpfung oder mit / abgekürzt. Werden die letzten beiden Symbole doppelt geschrieben, wird logisch verknüpft Ein Vergleich auf Gleichheit erfolgt mit ==.

Die Berechnung a=a+b kann mit a+=b abgekürzt werden Analog klappt das natürlich auch mit den anderen Operatoren.

Und schon wär s geschafft. Besonderheiten von C, die benutzt werden, sind aufgezählt. Auch Nicht-C-Programmierer durften nun mit den Listings keine Schwierigkeiten mehr haben.

Zu einem GEM-Entwicklungssystem gehört für viele auch ein Resource-Construction-Programm, mit dem man Menus, Dialoge und andere GEM-Elemente kreieren kann Natürlich ist dieses Programm nicht zwingend notwendig. es erleichtert die Arbeit jedoch ungemein. Außerdem sieht man gleich, wie Dialoge und die anderen Elemente später aussehen werden.

Bevor nun die Programmierung beginnt, legt man noch einen Plan fest, der beinhaltet, was das Programm können soll und was auf welche Weise realisiert werden kann. Bei der eigentlichen Programmierung ist es sehr empfehlenswert, rechnerspezifische Routinen in einem eigenen Modul unterzubringen. Bei einer Portierung reicht es dann, dieses Modul den neuen Gegebenheiten anzupassen. Auch die GEM-Umgebung trennt man besser von den diversen anderen Routinen Damit bleibt der Überblick gewahrt!

In einem kurzen Abriß sollen nun noch einige AES-Routinen vorgestellt werden. Logischer weise kann hier nicht alles erklärt werden, da eine ausführliche Erklärung viele, viele Seiten füllen wurde Eine vollständige Auflistung bleibt der Literatur überlassen.

Das AES besteht aus 11 Bibliotheken Die APPL-Bibliothek enthält die Funktion appl_init, die zur Anmeldung eines GEM-Programms benötigt wird Der zurückgegebene Wert gibt Aufschluß darüber, ob eine Anmeldung erfolgreich war oder nicht (Rückgabe: -1) War die Anmeldung nicht erfolgreich, darf der Rest des Programms nicht ausgeführt werden. Eine Auswertung des Wertes ist demzufolge unabdingbar (Es gibt übrigens viele Programme, die keine Auswertung vornehmen Man verbaut sich damit aber die Möglichkeit, daß das Programm unter jeder Bedingung lauffähig ist.) Ferner gehört in diese Bibliothek auch die Funktion appl_exit, die zum Abmelden des Programms benötigt wird. Sie darf nur dann ausgeführt werden, wenn appl_init erfolgreich war. Die Auswertung des Rückgabewertes scheint zur Zeit auf dem ST wenig Sinn zu haben, aber dies scheint eben nur so. Sobald ein zukünftiges Multitasking-GEM mehrere Programme abarbeiten kann, erhält der Rückgabewert seine Berechtigung.

/*************************************/
/* Resource-Set indicies für GEMPROG */   
/* ================================= */
/* Quelldatei: GEMPROG.H             */
/*************************************/

#define MENUE       0   /* Menübaum */
#define MNINFO      3   /* TITLE in Baum MENUE  */
#define MNDATEI     4   /* TITLE in Baum MENUB  */
#define ITINFO      7   /* STRING in Baum MENUE */
#define ITNEU       16  /* STRING in Baum MENUE */
#define ITOEFFNE    17  /* STRING in Baum MENUE */
#define ITSICHER    19  /* STRING in Baum MENUE */
#define ITSICALS    20  /* STRING in Baum MENUE */
#define ITAUSGAB    21  /* STRING in Baum MENUE */
#define ITENDE      23  /* STRING in Baum MENUE */

#define DESKTOP     1   /* Formula/Dialog */
#define BSPICON     1   /* ICON in Baum DESKTOP */

#define INFODIAL    2   /* Formula/Dialog */ 
#define INFOEXIT    4   /* BUTTON in Baum INFODIAL*/ 

#define LADEN       0   /* Alarm-String Index */

#define SPEICHER    1   /* Alarm-String Indax */

#define DOPPEL      2   /* Alarm-String Index */
#define AUSGABE     3   /* Alarm-String Index */

Listing 1

/**********************************************/
/* Atari ST-spezifische Routine(n)            */
/* ------------------------------------------ */
/* Quelldatei: INTERNA.C                      */
/**********************************************/

/* TOS ist gefragt! */

# include <tos.h>

/**********************************************/
/* Boot-Laufwerk                              */
/* Aufgabe: Ermittlung das Boot-Laufwerks     */
/**********************************************/

int boot_dev(void)

{   long old_super_stack 
    int ret_wert;

    old_super_stack = Super(0L); /* Supervisor-Modus */
    ret_wert = *(int*) 0x446;
    Super((void *) old_super_stack); /* User-Modus */ 
    return(ret_wert);
}

/**********************************************/

Listing 2

Zu der zweiten Bibliothek - der EVNT-Bibliothek - gehören Routinen zur Überwachung von Ereignissen. Für jeden Ereignistyp gibt es eine eigene Funktion. Die wichtigste Funktion ist jedoch evnt_multi. Sie ermöglicht den Empfang von verschiedenen Ereignissen. Das Beispielprogramm verwendet sie, um auf einen Mausklick, einen Tastendruck bzw. eine Menüauswahl zu warten. Zur genaueren Beschreibung des Mausklicks sind die Bits für die betrachteten Maustasten sowie die Anzahl der abzuwartenden Mausklicks zu setzen. Die Ermittlung der gedrückten Taste erfolgt über einen 16 Bit-Wert. Die oberen 8 Bits enthalten den Scancode - erlauben also die Auswertung der Funktionstasten - und die unteren 8 Bits den ASCII-Code. Wird ein Menüpunkt ausgewählt, erhält das Programm eine Nachricht. Diese beinhaltet Menütitel und -eintrag.

Die dritte, die sogenannte MENU-Bibliothek enthält Routinen zur Menüverwaltung. Häufig gebraucht wird menu_bar, um eine Menüleiste auf den Bildschirm zu bringen und auch wieder zu entfernen, und auch menu_tnormal um einen Menütitel zu invertieren bzw. die Invertierung aufzuheben. Nach jeder Auswahl einer der Optionen in einem Drop-Down-Menü bleibt nämlich der Titel invertiert. Die normale Darstellung wird erst durch Aufruf von menu_tnormal wieder erreicht. Benutzt man statt des Menüs die Tastatur, wird der entsprechende Menütitel invertiert, womit wieder die Funktion menu_tnormal Verwendung findet. Die Invertierung sollte unbedingt vorgenommen werden, damit der Programmbediener merkt, daß es auch ein Menü gibt, in dem das zum Tastendruck gehörige Kommando zu finden ist. Umgekehrt gehört zu dem passenden Menüeintrag auch ein Tastenkürzel, welches wieder auf die Tastenkombination hinweist.

Die vierte Bibliothek heißt OBJC-Bibliothek und umfaßt Routinen, die die Manipulation von Objekten erlauben. Wichtig sind insbesondere die Routinen objc_draw, objc_find und objc_offset. Objc_draw erlaubt die Ausgabe von Objekten, also auch von Dialogboxen, objc_find ermöglicht es, an einer bestimmten Position - etwa der Mausposition - ein dazugehöriges Objekt - beispielsweise ein Icon auf dem Desktop -zu ermitteln. Objc_offset berechnet die Position eines Objektes. Wer einen Objektbaum mit objc_add erweitern möchte, wird auf einige Probleme stoßen, denn der Speicherplatz für die Erweiterung muß vorhanden sein! Also ist das neue Objekt schon bei der Definition des Baums mitaufzunehmen oder aber der Baum an einen neuen Ort mit ausreichendem Speicherplatz zu kopieren.

Bibliothek fünf trägt den Namen FORM-Bibliothek und enthält die zur Verwaltung von Dialogen notwendigen Routinen form_do, form_dial, form_center und form_alert. Form_alert ist die einfachste darunter. Sie ist dafür verantwortlich, daß sogenannte Alertboxen ausgegeben und verwaltet werden, form_center zentriert ein Objekt oder in unserem Fall eine Dialogbox, form_dial reserviert den Hintergrund (zum Beispiel die sogenannte Rechteckliste für die Fenster benötigt diese Reservierung) und gibt ihn wieder frei. Restauriert wird der Hintergrund jedoch nicht automatisch! Für das Hintergrundfenster mit der Kennung 0 wird dem Programm die Arbeit abgenommen, aber nicht für die anderen Fenster. Aber keine Sorge: Das Programm erhält rechtzeitig eine Meldung über die EVNT-Funktion evnt_mesag bzw. evnt_multi. Form_dial mit dem Parameter FMD_FINISH kann übrigens auch dazu benutzt werden, um anderen Programmen eine "Nachricht" zu schicken, daß der Bildschirm zu erneuern ist.

Die GRAF-Bibliothek - die sechste - umfaßt Routinen, die etwa die bewegenden Rechtecke liefern. In dem Beispielprogramm findet graf_dragbox Verwendung, um dem Benutzer die Verschiebung von Icons zu ermöglichen und vor allem optisch nahezulegen. Außerdem sind hier auch die Routinen enthalten, mit denen man die Mausform ändern und den Status und die Position der Maustasten abfragen kann.

Die SCRP-Bibliothek trägt die Nummer sieben und beinhaltet die beiden Routinen scrp_read und scrp_write, die den Pfadnamen für das Scrap-Directory lesen bzw. setzen.

Mit fsel_input aus der Bibliothek FSEL - Nummer 8 - wird der bekannte File-Selector aufgerufen. Übergeben werden ein Pfad - beispielsweise "E:\ORDNER*.TXT" - und ein Dateiname "DATEI.TXT". Zurückgegeben werden der neue Pfad und der neue Dateiname.

Die umfangreiche neunte Bibliothek WIND umschließt alle Routinen zur Verwaltung von Fenstern. Die Routine wind_get wird zusammen mit dem Parameter WF_WORKYXWH benutzt, um die Ausmaße des Hintergrundfensters zu ermitteln, und wind_set in Verbindung mit WF_NEWDESK, um den neuen Desktop zu setzen. Ferner sperrt wind_update den Bildschirmaufbau störende Aktionen. Die Abfrage der Rechteckliste eines Fenster - die Teile eines Fensters, die sichtbar sind - geschieht ebenso mit wind_get. Übergibt man den Parameter WF_FIRSTXYWH, erhält man das erste Rechteck dieser Liste und mit WF_NEXTXWH die weiteren. Das Ende der Liste ist durch ein 0 Pixel breites und hohes Rechteck gekennzeichnet.

Mit rsrc_load aus der RSRC-Bibliothek, sie ist die zehnte, wird ein mit einem Resource-Construction-Programm angefertigtes Resource-File geladen. rsrc_free gibt den dafür benutzten Speicher vor dem Verlassen des Programms wieder frei. Die Adressen der einzelnen Objekte werden mit rsrc_gaddr ermittelt.

Die elfte Bibliothek - SHEL - enthält eine Routine, mit der man andere Applikationen starten kann, sowie weitere passende Funktionen. Die GEMDOS-Funktion Pexec wird dabei nicht benutzt. Shel_write teilt dem AES mit, daß nach Beendigung des laufenden Programms ein anderes zu starten ist. Damit ist es möglich, zwischen diversen Programmen zu wechseln, ohne daß dabei mehrere Programme im Speicher gehalten werden müssen.

Einen Überblick über die AES-Routinen hätten wir uns jetzt verschafft. Nun kann das Programmieren endlich losgehen. Oder doch nicht?

Erst müssen wir uns noch ein Resource-File verschaffen, welches wenigstens einige notwendig Dinge enthält. Bild 1 zeigt das Menü, Bild 2 das Desktop. Bild 3 die Dialogbox und Bild 4 die Alertboxen unseres Beispielprogramms. Richten Sie sich bei dem Entwurf bitte nach Ihrem persönlichen Resource-Construction-Programm. Die Namen der Elemente entnehmen Sie bitte den Bildern und dem Listing 1. Achten Sie aber bei der Gestaltung immer auf die bestehenden Konventionen. Zu den Konventionen aber gleich mehr.

Ein Resource-Construction-Programm ermöglicht die Gestaltung von Menüs, Dialogboxen, Alertboxen, freien Strings und Icons.

Freie Strings und Icons sind für das Beispielprogramm unerheblich und sollen daher nicht weiter betrachtet werden. Ebenso sind Alertboxen sehr einfach zu erstellen und damit recht unwichtig. Menüs und Dialogboxen haben eines gemeinsam: Es sind einfache Objektbäume. Ist Ihnen etwas aufgefallen? Das Desktop für das Beispielprogramm ist nicht aufgeführt! Es wird jedoch auch mit dem Resource-Construction-Programm entworfen.

Das Desktop ist "nur" eine Dialogbox. Exit Buttons existieren natürlich nicht. Sie nehmen eine Dialogbox ohne Rahmen und plazieren darauf die zukünftigen Objekte. Die Größe muß nicht mit der Bildschirmgröße übereinstimmen. Es würde auch keinen Sinn machen, die Bildschirmgröße zu berücksichtigen, da diese nicht bekannt sein kann. Das Desktop wird nach dem Laden der Resource-Datei den örtlichen Verhältnissen angepaßt.

Wenn Sie das Resource-File haben, kann die Arbeit beginnen. Zuerst erstellen wir ein Modul mit den systemspezifischen Routinen. In unserem Beispiel handelt es sich lediglich um eine Routine, die das Bootlaufwerk ermittelt. Die Kenntnis über das Bootlaufwerk wird für den Scrap-Pfad benötigt. Zu diesem Modul gehören die Listings 2 und 3. Die im Listing 4 befindlichen Deklarationen reservieren Namen für die Auswertung der Tastaturereignisse. Die Liste kann bei Bedarf erweitert werden. Eine Auflistung der sogenannten Scancodes findet sich in der Literatur. Nun noch ein wenig zu den Konventionen. Im Menü gehören hinter jeden Eintrag, der eine Dialogbox oder ein Fenster zur Folge hat, drei Punkte, das Tastenkürzel gehört an den rechten Rand des Eintrags. Im sogenannten Desk-Menü findet man einen Eintrag, mit dem man eine Programminformation abrufen kann. GEM 2.0 setzt statt des Menütitels "Desk" automatisch den Programmnamen ein. Es bietet sich also geradezu an, dies unter dem aktuellen ST-GEM nachzuahmen und den Programmnamen anstelle von "Desk" einzusetzen. Allerdings muß dies schon bei dem Entwurf des Menüs geschehen. Unter der aktuellen GEM-Version auf dem ST findet man im zweiten Menü von rechts die Dateioperationen und auch den Eintrag, mit dem das Programm beendet werden kann.

Menüeinträge, die nicht selektiert werden können oder dürfen, stellt man gesperrt dar. Beispielsweise hat das Speichern eines Textes wenig Sinn, wenn gar kein Textfenster geöffnet ist. Auch hat es wenig Sinn, extra für Accessories ein anderes Menü auf den Bildschirm zu bringen. da Accessories ein Zubehör zum laufenden Programm und nicht getrennt laufende Applikationen sind. Achten Sie auch immer darauf, daß Accessories wie zum Beispiel das Kontrollfeld Fenster öffnen können und daher verschiebbar sein müssen. Nehmen wir hierzu ein (Negativ-Beispiel. Einige Programme lassen zu, daß Accessories aufgerufen werden. Für GEM-Programme ist das natürlich selbstverständlich. Ruft man nun das Kontrollfeld auf und verschiebt es, wird von dem Programm der komplette Bildschirm neu gezeichnet. Das Kontrollfeld ist zwar nach wie vor geöffnet, aber zu sehen ist es nicht mehr.

Vom Benutzer einstellbare Werte wie Icon-Positionen werden in einer Datei mit der Extension INF abgespeichert. Der Name dieser Datei ist mit dem des Programms identisch. In unserem Fall heißt das Programm GEMPROG und damit die Programmdatei GEMPROG.PRG, die Parameterdatei hieße dann GEMPROG.INF. Die Resourcedatei trägt übrigens immer die Extension RSC, also heißt sie hier GEMPROG.RSC.

In den Dialogboxen sollten die Buttons oder Felder zum Verlassen der Dialogbox immer an ähnlichen Stellen - beispielsweise nur am unteren Rand - zu finden sein und sich klar vom restlichen Inhalt abheben. Es ist sehr lästig, wenn man erst verschiedene Elemente anklicken muß, um einen Dialog zu beenden.

Die Mausform ist in der Regel ein Zeiger. Für den Fall, daß das Programm etwas mehr Zeit benötigt, ist die Form einer Biene oder einer Sanduhr (je nach GEM-Version) zu wählen. Wird ein Objekt bewegt, erscheint die Maus (nicht der kleine graue Kasten!) in Form einer flachen Hand. Um eine Sache zu dimensionieren - beispielsweise ein Fenster -, wird die Hand mit dem Zeigefinger benutzt, und bei Texteingaben findet der Balken Verwendung.

Generell ist innerhalb des Programms auf innere Konsistenz zu achten. Es dürfen nicht ähnliche Dinge auf verschiedene Arten bedient werden können. Damit ist natürlich nicht gemeint, daß nicht parallel zum Menü auch die Tastatur bedient werden darf, sondern vielmehr, daß beispielsweise Buttons in Dialogboxen mal oben und mal unten plaziert werden.

Bei der Programmierung sollte ferner noch auf ein paar andere Dinge geachtet werden. Ein gelegentlicher evnt_timer-Aufruf bei längeren Operationen gewährleistet, daß auch andere Applikationen Weiterarbeiten können. Der Dreifachklick für diverse Aktionen ist ein Kunststück für den Zeigefinger, also bleibt man beim Einfach- oder Doppelklick. Ein Icon für die Scrap-Ablage sieht gut aus und hat seine Berechtigung. Es kann Information darüber geben, ob Dateien in der Scrap-Ablage bereitliegen. Bei der Textausgabe über die VDI-Funktionen erreicht man einen schnelleren Bildschirmaufbau, wenn der Text auf einer Byte- oder noch besser einer Word-Grenze beginnt. Der Wiederaufbau eines Textfenster läuft schneller ab, wenn kein Clipping durchgeführt werden muß. Stattdessen berechnet man den Platz für den Text und gibt nur entsprechend viel aus Icons lassen sich frei auf dem Desktop plazieren. Für den Benutzer ist es jedoch praktischer, wenn sie sich nur innerhalb eines Raster positionieren lassen. Beispielsweise könnten die Icon-Positionen auf Byte-Grenze festgelegt werden.

Ist ein Programm fertig, beginnt die Testphase. Zu einem umfangreicheren Test gehört auch ein Probelauf auf einem Farb- und einem Monochrommonitor. Auch der Ganzseitenmonitor und andere GEM-Versionen sollten dazugehören. Aber keine Angst, einen Ganzseitenmonitor oder GEM 2.0 brauchen Sie für einen Test nicht extra zu kaufen. Die Lauffähigkeit auf einem Ganzseiten-Monitor läßt sich mit BigScreen (von J. F. Reschke) oder mit Protos (von M. Schneider) testen. Einzige Voraussetzung ist eine TOS-Version ab 1.2. Von GEM 2.0 ist ein Demo erhältlich, das zum Testen vollauf reicht. Stellen Sie sich einen Fragenkatalog zum Testen: Laufen Accessories - auch mit Fenstern - einwandfrei? Kommt es nicht zu Abstürzen unter anderen Hardware-Bedingungen? Und so fort. Testen Sie Programme nicht alleine, lassen Sie auch Laien an das Programm! Soviel zum Testen.

Und nun? Tja, jeder Artikel hat mal ein Ende. Aber Sie lesen doch im nächsten Monat weiter? Das eigentliche Beispielprogramm finden Sie dann in der nächsten Ausgabe.

Bis dann...

Literatur:

1. Atari ST Profibuch, H.-D. Jankowski/ J. F. Reschke/ D. Rabich. Sybex 1987/88/89

2. GEM Programmier-Handbuch, P. Balma/ W. Filler, Sybex 1987/88

3. ProfessionelGEM, T. Oren, ANTIC 1985/86

4. Windows unter GEM, A. Lötscher, ST Computer ab 5/89

   // / Quelldatei SCANKEY.H / //

   if 1defined( __SCANKEY )

   define __SCANKEY

   define K_Q 16

   define K_O 24

   define K_A 30

   define K_S 31

   define K_N 49

   /* Bei Bedarf können hier die / / weiteren Scancodes deklariert / / werden. */

   endif

Listing 3

/*************************/
/* Quelldatei: INTERNA.H */
/*************************/

# !defined( __INTERNA )
# define  __INTERNA

int boot_dev(void)

# endif

Listing 4

Dietmar Rabich

---

---