Do-it-yourself: Objekte und Resourcen, Teil 1

»GEM« bietet bekanntlich eine relativ magere Auswahl an Objekttypen. Wir wollen die Typenvielfalt erweitern und geeignete Routinen vorstellen, mit denen sich solche neuen Objekte bequem über Bibliotheken in eigene Programme einbinden lassen.

Als eine der notwendigen und praktischen Grundlagen stellen wir heute die Bibliothek »Easy-GEM«, mit deren Aufbau wir bereits im GEM-Kurs »Von Dialogen und Dialog-Boxen« (ST Magazin ab Ausgabe 7/90) begonnen haben, vor. Um diese Bibliothek geradlinig aufzubauen, modularisieren wir sie. So entstehen die in Tabelle 1 aufgeführten Module bzw. Funktionen. »OpenWorkstation« und »CloseWorkstation« werden für die »Userdefined Objects« und die Hintergrundrestaurierung benötigt, da diese auf den VDI-Funktionen aufbauen. Auch die Funktionen »TreeWalk« und »GetParent« kommen hier zum Einsatz. »TreeWalk« ruft für alle Objekte eines Objektbaums - also insbesondere die Objekte einer Dialogbox - eine Funktion auf, deren Adresse man »TreeWalk« mitgeben kann. »TreeWalk« arbeitet rekursiv, was die Funktion einerseits kurz und einfach hält, andererseits für Nichtgeübte unüberschaubar macht. Aber keine Angst: Die Routine ist bald eingeübt! »GetParent« ermittelt für ein beliebiges Objekt das Parent-Objekt. Somit kann man Abhängigkeiten vom Parent-Objekt herstellen. »SetDisabled« und »SetSelected« kürzen das Setzen der Stati »DISABLED« und »SELECTED« ab. Mit »SetText« und »GetText« kann der String für die Textobjekttypen gesetzt bzw. ermittelt werden. Die »FileSelector-Routine« ruft die AES-Funktion »fsel_input« oder ab GEM 1.4 bis GEM 2.0 »fsel_exinput« auf. Die älteren TOSVersionen mit GEM-Versionsnummer unter TOS 1.4 bzw. die GEM-Versionen ab 2.0 beinhalten die Routine fsel_exinput nicht. Tritt bei der Ausgabe des File-Selectors ein Fehler auf, z. B. wenn kein Speicherplatz für das Directory reserviert wurde, dann erscheint automatisch eine Alertbox.

Die beiden Routinen »DialBegin« und »DialEnd« bereiten einen Dialog vor bzw. schließen ihn ab. »DialBegin« sperrt alle Fensterausgaben: damit niemand dazwischenfunkt; übernimmt die Mauskontrolle: damit auch bei Accessories die Slider funktionieren; stellt den Mauszeiger auf den wohlbekannten Pfeil ein und reserviert den Hintergrund. Letzteres geschieht aber nicht nach der herkömmlichen Methode mit »formdial(FMD_START, ... )» sondern mit einer eigenen Restaurierung. Hierzu wird Speicher reserviert. Geht dies nicht, greift »DialBeginn« doch auf die gewohnte Methode zurück. In den reservierten Speicher wird mittels der VDI-Funktion »vro_cpyfm« der Hintergrund kopiert. Danach kann dann die Dialogbox auf dem Bildschirm ausgegeben werden. Der ganze Aufwand lohnt sich, da die spätere Restaurierung des Hintergrunds sonst sehr viel Zeit kostet. »DialEnd« kopiert nach dem ausgeführten Dialog den Hintergrund auf den Bildschirm zurück und gibt den Speicher wieder frei. Die Funktion »DoDial« führt einen vollständigen Dialog durch. Dies bietet sich dann an, wenn keine eigene aufwendige Dialogverwaltung benötigt wird. Da oft nur mit einem einfachen Dialog gearbeitet wird, rentiert sich auch diese Funktion.

Die einzelnen Module werden compiliert und zu einer neuen Bibliothek zusammengesetzt. Das hier und in den beiden nächsten Folgen unserer Serie benutzte Entwicklungssystem ist »Turbo-C«. C wurde wegen der guten Modularisierungs- und Strukturierungsmöglichkeiten gewählt, alternativ zu einem Modula-2-System. Unser kleines Beispielprogramm zeigt die Einbindung der Easy-GEM-Bibliothek in eigene Programme. Sie müssen jedoch vor dem Übersetzen des Beispiels noch mit Ihrem Resource-Construction- Programm eine Ressource-Datei mit einer Dialogbox anlegen (Abb.). Die Dialogbox besteht lediglich aus zwei Strings und einem Button, der mit den Flags »SELECTABLE«, »DEFAULT« und »EXIT« gekennzeichnet ist.

Und jetzt noch zur Datei »PORTAB.H«. Diese wird häufig bei GEM-Programmen benutzt, um eine Unabhängigkeit vom Rechner und Entwicklungssystem zu erreichen. Vielen Entwicklungssystemen, wie z. B. »Megamax Laser C«, liegt eine solche Datei bei. Wenn nicht, kann man sie sich leicht anlegen. Wem diese Datei fehlt, der muß sich diese anlegen, zumal viele der in großen Buchstaben geschriebenen Bezeichnungen auch normal vorkommen. Besonderes Augenmerk verdienen im Beispiel von Turbo-C WORD (=int), LOCAL, MLOCAL (=static) und BYTE (=char). In der nächsten Folge dreht sich alles um erweiterte Objekttypen.

(uw)

Literatur:

[1] Atari ST Profibuch, H.-D. Jankowski, J.F. Reschke, D. Rabich, Sybex Düsseldorf 1990
[2] GEM-Kurs: Von Dialogen und Dialog-Boxen, D. Rabich, ST-Magazin 7/90ff, Markt & Technik Haar 1990
[3] GEM Programmier-Handbuch, P. Balma, W. Fitler, Sybex Düsseldorf 1988
[4] Professionel GEM, T. Oren, ANTIC Publishing 1985/86

Tabelle 1: Aus diesen Modulen besteht Easy-GEM:

Listing 1: CLOSWORK.C schließt eine virtuelle Arbeitsstation
Listing 2: DBEGIN.C bereitet einen Dialog vor
Listing 3: DEND.C räumt den Bildschirm auf
Listing 4: DODIAL.C führt den Dialog durch
Listing 5: EASYGEM.H - Diese Header-Datei binden Sie in Ihr Programm ein
Listing 6: EASYGEM.PRJ - Das Projektfile baut die Bibliothek zusammen
Listing 7: FILESEL.C gibt eine File-Selektor-Box aus
Listing 8: GETPAREN.C ermittelt den Parent im Objektbaum
Listing 9: GETTEXT.C ermittelt Text-Strings
Listing 10: OBJCDRAW.C gibt ein Objekt aus
Listing 11: OBJCRDRA.C gibt ein komplettes Objekt aus
Listing 12: OPENWORK.C öffnet eine virtuelle Workstation
Listing 13: SETDISAB.C setzt bzw. löscht den DISABLED-Status
Listing 14: SETSELEC.C behandelt den SELECTED-Status
Listing 15: SETTEXT.C setzt einen String
Listing 16: TREEWALK.C durchläuft den gesamten Objektbaum:

Download EasyGEM (9 KB)