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

In der letzten Folge stellten wir die Bibliothek »Easy-GEM« vor. Mit ihrer Hilfe verwenden wir im heutigen Beispielprogramm ein relativ selten genutztes Feature des GEM.

Der Standardobjekttyp wird in dem Word-großen Wert »ob_type« der OBJECT-Struktur definiert, genauer gesagt, sogar nur im unteren Byte. Das obere Byte wird vom GEM selbst vollständig ignoriert. Es steht daher zur freien Verfügung und legt den erweiterten Typ fest. Dieses Byte kann man prinzipiell auf zwei Arten verwerten. Einerseits nutzt man die Bits einzeln, um so weitere, selbst festgelegte »Quasi-Stati« zu definieren, womit es bis zu acht weitere Quasistati gibt. Andererseits ist es möglich, dort eine fortlaufende Nummer unterzubringen, die entsprechend viele neue Objekttypen ermöglicht.

C-Programmiererinnen und -Programmierern steht nun noch der Weg offen, eine Mischform aus den Quasistati und der Numerierung zu realisieren. Die Bitfelder bieten sich hier geradezu an. In unserem Beispiel verwenden wir die Numerierung der erweiterten Typen beginnend mit dem Zahlenwert 100. Eine Resourcendatei mit erweiterten Typen wird genauso angelegt wie jede normale Resourcendatei auch. Den Effekt der eigenen Manipulationen an den Objektbäumen kann man beim Entwurf der Ressourcen jedoch nicht betrachten. Man ist hier darauf angewiesen, abzuschätzen, wie sich der programmtechnisch realisierte Effekt auswirkt. Unter Umständen kann es nötig sein, erst die Ressourcen mit dem eigenen Programm zu testen und dann weiter anzupassen. Haben Sie die Resourcendatei nach eigenen Wünschen angelegt, so denken Sie nun daran, die erweiterten Typen zu verankern. Die meisten Resource-Construction-Programme verfügen über diese Fähigkeit. Auf den beiden Bildern ist der dazugehörige Eingabedialog des mit »FTL Modula-2« ausgelieferten »WERCS« und des zu »Megamax Modula-2« gehörigen »Kuma-RCP« zu sehen. Die Versionen der Resource-Construction-Sets von »Digital Research/Atari« bieten zwar prinzipiell die Möglichkeit der erweiterten Typen, jedoch verhindert ein Programmierfehler die Ausnutzung bzw. korrekte Eingabe.

Wer ferner die Ressourcen in sein Programm fest einbinden muß, was ja z.B. bei Accessories der Fall ist, hat kaum eine Chance, dies ohne viel Arbeit zu erledigen. (In der letzten Folge werden wir zeigen, wie es gemacht wird.) Das DR-RCS erlaubt keine korrekte Eingabe der erweiterten Typen, gibt dafür aber die Resource auch als fast korrekten C-Quellcode mit den erweiterten Typen aus. Die meisten anderen erlauben die korrekte Verwaltung der erweiterten Typen, sperren sich aber bei der Ausgabe des C-Quellcodes. Als brauchbar haben sich beispielsweise folgende Wege erwiesen:

1. Resourcendatei mit Kuma-RCP anlegen, die Definitionsdatei (mit Extension RSD) in eine für das DR-RCS passende Datei umwandeln, Resourcendatei laden, wieder (mit C-Quellcode) ausgeben, C-Quellcode nacharbeiten.

2. Resourcendatei mit Kuma-RCP anlegen, mit Hilfe des Shareware-Programms »RCS2C«, welches beispielsweise in der Mailbox »Maus Münster« abgerufen werden kann, in C-Quellcode umwandeln.

Legen Sie sich nun eine Resourcendatei mit einer Dialogbox wie in Abb. 1 an. Je drei Strings sind als Childs einer Box zusammengefaßt. Der Button wird benötigt, damit der Dialog verlassen werden kann. Die Strings der oberen Box erhalten als erweiterten Typ die Nummer 101, die in der mittleren Box eine 102 und die in der unteren Box eine 103. Hierbei soll 101 für zentrierten Text, 102 für linksbündigen und 103 für rechtsbündigen Text stehen. Die Ausrichtung erfolgt in Abhängigkeit des Parents. Sobald die Ressourcendatei fertig ist, geben Sie das Listing ein und übersetzen es. War die Eingabe korrekt, so erscheint die Dialogbox so, wie es in Abb. 2 zu sehen ist.

Die Auswertung der erweiterten Objekttypen erfolgt, sobald die Resourcendatei geladen ist. Nach dem Laden wird für jede Dialogbox (wir haben nur eine) die Adresse ermittelt, wie es auch bei normalen Ressourcen der Fall ist. Anschließend wird jedoch die Routine »Treewalk« mit der Funktion »tune_dial« aufgerufen. Treewalk als EasyGEM-Routine haben wir in der letzten Folge vorgestellt. Sie rief für jedes gefundene Objekt die ihr übergebene Funktion auf. Dies nutzen wir mit tune_dial aus, um die erweiterten Objekttypen auszuwerten.

Die Funktion tune_dial besitzt als Parameter einen Pointer auf einen Objektbaum und den Index eines der Objekte. tune_dial prüft nun, ob ein erweiterter Objekttyp definiert wurde und wertet diesen gegebenenfalls aus. So wird beispielsweise im Fall des zentrierten Textes erst das Parentobjekt (mit der Easy-GEM-Routine Getparent) ermittelt und dann der String bezogen auf das Parentobjekt ausgerichtet. Die erweiterten Objekttypen werden wir in der nächsten Folge dazu benutzen, um Userdefined Objects in Dialogboxen einzubinden. Bis dahin wünsche ich Ihnen viel Freude bei Ihren GEM-Experimenten.

(uw)

Literatur:

[1] Atari ST Profibuch, H-D. Jankowski, J. F. Reschke, D. Rabich, Sybex Düsseldorf 1990
[2] GEM Programmier-Handbuch, P. Balma, W. Fitler, Sybex Düsseldorf, 1988
[3] Professional GEM, T. Oren, ANTIC Publishing 1985/86

Download Listings