Generationswechsel: GEM-Programmiersystem »ACS«
Die Nachfolger des Urvaters der ersten Resource Construction Sets übertrafen diesen vor allem in Sachen Zuverlässigkeit und Umfang. Die dritte Generation, deren erster Vertreter hier zum Test ansteht, widmet sich darüber hinaus der Entwicklung vollständiger Applikationen.
Mit Sicherheit würde der Autor des Programms »ACS« (»Application Construction System«) die Zuordnung von ACS zu den Resource-Editoren als Denunziation empfinden, wenngleich ein solcher darin enthalten ist. So versucht ACS vielmehr, den größten Teil des Event-Handlings gleich bei der grafischen Gestaltung einer Applikation mit zu organisieren. Ein GEM-Objekt besteht nicht mehr nur aus dem reinen Erscheinungsbild, sondern zusätzlich aus Eigenschaften, die teilweise vorgegeben sind und sich teilweise erst durch die Zuordnung von Funktionen bilden.
Umgang mit dem Umfang
Zum Umfang gehört eine doppelseitige Diskette und ein etwa 150 Seiten starkes, fest gebundenes Handbuch. Im großen ganzen besteht ACS aus drei Teilen. Dem eigentlichen Programm, einer Header-Datei für die Sprache C und einer Funktionensammlung, zusammengefaßt in einer Bibliothek (ohne Quelltext). Desweiteren sind noch zahlreiche Beispiele beigelegt, die das Entwickeln von eigenen Applikationen veranschaulichen sollen. Das fertige Produkt, welches ACS erzeugt, ist entweder eine Objektdatei (DR-Format) oder C-Quelltext, der sich bis jetzt nur mit Turbo- oder Pure-C übersetzen läßt.
Um daraus nun ein Programm zu fertigen, sind der Startup-Code, alle C-Bibliotheken (inkl. PC/TC-GEMLIB.LIB), die neue ACS.LIB und mindestens ein weiteres Modul, das die Einsprungfunktionen bereitstellt, in einer Projektdatei zusammenzufassen. Kleinere Handarbeiten sind also nach wie vor notwendig.
Baukastenprinzip
Nach dem Start präsentieren sich drei Icons (»Allgemein«, »Neu« und »Papierkorb«) und ein recht bescheidendes Menü auf dem Desktop. So fragt man sich, wo denn die Funktionen hinter den knapp 200 KByte des Programmes bleiben. Ein Doppelklick auf das Neu-Symbol öffnet ein Fenster (Generelles-Fenster in Bild 1), in dem die Teilekategorien der zukünftigen Applikation, jeweils wiederum als Icon repräsentiert, aufgelistet sind. Zu diesem Zeitpunkt erklärt sich auch die knapp gehaltene Menüzeile, denn das geöffnete Fenster enthält ein eigenes Menü. Erwähnenswert an dieser Stelle ist die Tatsache, daß ACS mit sich selbst entwickelt wurde.
Die Kategorien teilen sich in zwei Lager auf. Mit den einen lassen sich neue Komponenten für das eigene Programm erzeugen, während die anderen zur Auflistung und Anschauung dienen. Unser Interesse liegt natürlich bei den erzeugenden Icons, als da wären: Fenster, Menüs, Popups, allgemeine GEM-Objekte und Alert-Boxen.
Menüs und Popups sind im Prinzip nur spezielle GEM-Objekt-Anordnungen, sind also nichts revolutionäres. Der Trick besteht nun darin, daß sich jedem Menüeintrag eine Funktion zuordnen läßt. Wählt man später diesen Menüpunkt (eventuell eingegebene Tastenkürzel sind mitberücksichtigt), springt das Programm automatisch zur angegebenen Funktion.
Für die zusätzlich nötigen Informationen reichte die normale Objektstruktur nicht aus. Deshalb entschied sich der Autor für einen etwas unkonventionellen Weg. Ein spezielles Flag (aus »ob_flags«) kennzeichnet dieses Objekt als ein besonderes. Ein besonderes insofern, als es genau doppelt so groß ist wie ein normales Objekt. Diese Tatsache verschließt sich weitgehend dem Programmierer, da alle Objektebäume richtig reloziert bleiben (»ob_head«, »ob_next« und »ob_tail«). Auch die Bibliotheksfunktionen von ACS berücksichtigen diesen Aspekt.
In dem dadurch geschaffenen Freiraum ist so reichlich Platz für zusätzliche Informationen, wie etwa einen Zeiger auf eine Funktion, die ACS beispielsweise im Falle eines Mausklicks aufruft.
(Schau-)Fenster
Mit Hilfe einer großen »nicht modalen« Dialogbox, die sich also in einem Fenster befindet und deshalb größer als der Bildschirm sein darf (auch ein ACS-Produkt), definiert man alle Fenster, die das Programm später einmal schmücken sollen. Auch die Namen eventueller Funktionen, die auf die verschiedenen Ereignisse eines Fensters reagieren sollen, sind hier einzugeben. Dazu verwaltet das neue Programm eine Struktur, die bei jedem Fensteröffnen dynamisch angelegt wird.
Die Fensterverwaltung ist ohnehin eine der Stärken von ACS. Ohne eigenes Zutun lassen sich bis zum »Speicherplätzen« Fenster öffnen. Verteilt das GEM keine weiteren Fenster-Handies, weil die Maximalzahl (derzeit acht) erreicht ist, schließt ACS automatisch die hintersten Fenster. Trotzdem bleiben diese organisatorisch erhalten. Eine ebenfalls bereitstehende Funktion, die auf Tastendruck zwischen den Fenstern wechselt, öffnet dann gegebenenfalls ein zuvor geschlossenes Fenster. Automatisieren läßt sich auch die repräsentative Darstellung der Fenster durch ein Icon auf dem Desktop.
Soll beispielsweise ein Fenster einen »FÜLLER« erhalten, bestimmt man das mit ACS. Eine eigene Funktion, die einen Klick auf den FÜLLER verarbeitet, ist jedoch optional, da sich in der ACS-Bibliothek für die meisten Ereignistypen Default-Funktionen befinden. Ein anderes Beispiel ist die ACSinit-Funktion. Diese Funktion besteht nur aus einem »return ( OK )«. Eigene Programme erweitern diese Funktion um gewünschte Routinen zur Initialisierung des Programms, bevor der Desktop der Applikation erscheint.
Generischer Desktop
Ausgehend von dem generischen Desktop, dem Grundgerüst jeder von ACS erstellten Applikation, besteht die Programmierung nicht mehr aus hierarchisch aufgebauten Funktionen, sondern nur aus einer losen Sammlung von Routinen. Angefangen bei der Funktion »mainO« und der kompletten GEM-Initialisierung, bis zur evnt_multi-Schleife für den Desktop, stehen ACS-Funktionen bereit. Diese Art der Programmierung ist mit Sicherheit gewöhnungsbedürftig. Unter welchen Bedingungen welche Funktionen aufzurufen sind, läßt sich nämlich nur noch innerhalb von ACS ermitteln.
Auch das Debuggen gestaltet sich anders. Da die Event-Verteilungsfunktion in den Libraries steckt und von dort alle selbst geschriebenen Funktionen aufruft, läßt sich wegen fehlendem Quelltext der Libraries die kritische Stelle nicht mehr über die »Trace«-Funktionen lokalisieren. Einziger Ausweg bleibt die Verwendung von Breakpoints. Dieser Umstand gewinnt zusätzlich an Bedeutung, da der Turbo/ Pure-C Debugger zwar die Trace-Funktionen auf Tastenkürzel hat, nicht aber das Break-Punkt setzen. Der Griff zur Maus ist somit unabdingbar.
Eine ganze Reihe von Funktionen widmen sich der Verwaltung von Icons. Sowohl die auf dem Desktop, wie auch die aus den Fenstern. Anhand weiterer Eigenschaften, die die Icons näher spezifizieren, übernimmt der ACS-Event-Handler die gröbsten Aufgaben. Um etwa bei gedrückter linker Maustaste ein Icon von einem inaktiven Fenster in ein anderes Fenster oder gar auf ein anderes Icon zu verschieben (mit »Shift« kopieren), bedarf es keiner einzigen Programmzeile. Gleiches gilt, wenn mehrere Icons selektiert sind. Natürlich befreit ACS den Programmierer nicht von der Arbeit, die operativen Funktionen hinter den grafischen Aktivitäten selbst zu schreiben.
Notenvergabe
Bedenkt man einmal, daß ACS keine Resource-Dateien mehr erzeugt, und somit nicht an deren Konventionen gebunden ist, ließe sich noch wesentlich mehr automatisieren. Unklar bleibt auch, für wen ACS nun gedacht ist, denn das Handbuch ist für GEM-Einsteiger eindeutig zu knapp gehalten. Dies läßt sich auch nicht durch die vielen beigefügten Beispiele kompensieren. Für den erfahreneren Programmierer, der sich wahrscheinlich im Laufe der Zeit eine eigene GEM-Bibliothek geschrieben hat, stellt sich die Frage, ob er sich auf ein doch recht starres Konzept einläßt und den ACS-Funktionen ein fehlerfreies Abarbeiten zutraut. Der Preis, rund das Doppelte eines guten Resource-Editors, dürfte eine Entscheidung zu Gunsten von ACS ebensowenig erleichtern. (ah)
WERTUNG
Name: ACS, Application Construction System
Preis: 198 Mark
Hersteller/Vertrieb: Stefan Bachert, Böblingerstr. 37 W-7038 Holzgerlingen
Stärken: großer Funktionsumfang □ Betriebssicherheit □ derzeit ohne Konkurrenz □ einfache Umsetzung von Standard-GEM-Problemen
Schwächen: Gewöhnungsbedürftiges Konzept □ inkonsequente Benutzerführung □ magerer Icon-Editor
Fazit: Wer öfter mal auf die Schnelle ein GEM-Programm schreiben muß, hat keine andere Wahl.
Jürgen Lietzow