Viel gewünscht: GEM bietet die Möglichkeit in Dialoge eigene Objekte einzubinden.
Viele haben schon versucht, Dialogboxen mit Texten in einer anderen Darstellung oder Größe in Dialoge, einzubinden oder das Desktop mit speziellen Objekten zu verzieren. Meist landete man dabei in eigenen Dialogverwaltungen, die insgesamt unzureichend sind, weil so ohne weiteres keine Radio-Buttons mehr möglich sind, eine Abhängigkeit von der Bildschirmauflösung entsteht oder weil die Bedienung gänzlich anders ist, als man es vom GEM her gewohnt ist. Solche Probleme lassen sich durch Objekte vom Typ »G_USERDEF«, die Userdefined Objects, beseitigen. Es ist lediglich nötig, eine Routine aufzubauen, die einen neuen Objekttyp ausgibt. Unser Ziel soll es sein, drei neue Objekttypen zu definieren:
Beginnen wir mit dem üblichen Anlegen der Resourcedatei. Welchen Objekttyp Sie für die späteren Objekte des Typs G_USERDEF wählen, ist unerheblich. Im Beispiel wurden einfache Rechtecke genommen, da man hiermit den Platzbedarf recht gut abschätzen kann. Das Rechteck, das für die Linie steht, erhält als erweiterten Objekttyp die Nummer 110, der künftige Ankreuz-Button die Nummer 111 und das künftige Rechteck mit den abgerundeten Ecken die Nummer 112.
Geben Sie das Listing ein, und versuchen Sie Ihr Glück mit dem neuen Dialog. Es müßte klappen. In der Annahme, daß Sie Erfolg mit dem neuen Dialog hatten, wollen wir noch die Erklärung nachreichen. Ein Objekt vom Typ G_USERDEF benötigt im Programm (mindestens) eine Variable vom Typ »USERBLK« (UserBlock). Dieser User-Block beinhaltet zwei Werte, von denen einer ein Pointer auf die Funktion ist, die zur Ausgabe des Objektes dient. Der andere Wert kann individuell verwertet werden, was in unserem Beispiel jedoch nicht nötig ist, da wir allgemeingültige Objekte implementiert haben. Weiterhin muß der Typ des Objekts auf G_USERDEF gesetzt werden. Diese Änderung ist frühestens im Programm (und nicht schon im Resource-Construction-Programm) möglich und sinnvoll, da erst hier der UserBlock und die Ausgabefunktion existiert.
Als letzte Änderung muß »ob_spec« der OBJECT-Struktur auf den Userblock zeigen. Mit diesen drei kleinen Änderungen ist ein Userdefined Object prinzipiell eingebunden. Da wir die Änderung jedoch systematisch vornehmen wollen, erweitern wir die »tune_dial«-Routine, die in der letzten Folge vorgestellt wurde. Jetzt fehlen nur noch die Objektausgaberoutinen.
Diese erhalten als Parameter einen Pointer auf eine Struktur vom Typ »PARMBLK« (Parameterblock) und geben ein Word zurück. Es enthält den Status, wie er vom GEM zu setzen ist; in der Regel der gegenwärtige Status, der Bestandteil des Parameterblocks ist. Soll ein spezieller Status selbst verwaltet werden, ist dies von der entsprechenden Funktion auszuwerten. Der Ankreuz-Button gibt für den Fall, daß er den Status »SELECTED« besitzt, ein Kreuz aus. Das dazugehörige Bit wird aus dem Rückgabewert entfernt. Der Vorteil ist, daß nun SELECTED durch ein Kreuz dargestellt wird, die Abfrage auf gesetzt oder nicht gesetzt durch das auswertende Programm jedoch immer noch mit der Prüfung des SELECTED-Status erfolgt. Der Parameterblock liefert die Information, welcher Teil des Objektes neu zu zeichnen ist. Dieses Clipping-Rechteck muß gesetzt werden. Der Rest bleibt Ihnen überlassen.
Generell sollten in einem korrekten GEM-Programm keine Annahmen über Monitorauflösungen, Zeichengrößen etc. gemacht werden, da ein Programm sonst unter Umständen mit selbstdefinierten Objekten nicht mehr in allen Varianten läuft. In den Ausgaberoutinen dürfen übrigens nur »VDI«-Aufrufe, jedoch keine »AES«-Aufrufe gemacht werden.
Wer sich weiter über das GEM und seine Möglichkeiten informieren will, der findet in der Artikelreihe »Professional GEM« [3] eine wahre Fundgrube von Tips.
(uw)
Literatur:
[1] H.-D. Jankowski, J. F. Rescke, D. Rabich, »Atari ST Profibuch«, Sybex Düsseldorf 1990
[2] P. Balma, W. Fitler, »GEM Programmier-Handbuch«, Sybex Düsseldorf 1988
[3] T. Oren, Professional GEM, Antic Publishing 1985/86