Konstruktive Resourcen - Ein Vergleichstest von Resource Construction Sets

Eines der wichtigsten Utilities beim Erstellen von GEM-Programmen ist ohne Zweifel das Resource Construction Set. Dieses schmucke Programm, das dazu dient, auf möglichst einfache Art Dialogboxen und Menüleisten zu erstellen, und ursprünglich von Digital Research als Teil des Entwicklungspakets herausgebracht wurde, hat inzwischen ein paar Geschwister und einen Nachfolger bekommen, die vorgeben, es mit ihm aufnehmen zu können oder besser zu sein. Dies ist sicherlich ein Grund, diese unterschiedlichen Resource Construction Sets einmal unter die Lupe zu nehmen.

Ein Adventure im Jahre 1985

Als ich im Oktober 1985 voller Stolz vor meinem 520er (natürlich damals noch ohne Plus und 512 kB zusätzlich) saß und mir anschaute, was er alles zu bieten hatte, beschäftigte ich mich mit den wenigen Dingen, die ich zu diesem Zeitpunkt besaß und das war nicht mehr als das Entwicklungspaket. Am meisten fiel dabei ein Programm auf, das den vielsagenden Namen RCS besaß. Einmal ganz abgesehen davon, daß ich natürlich keinerlei Ahnung hatte, wie man mit GEM umzugehen vermag, brachte ich auch mit viel Engagement innerhalb des Programms nicht viel zusammen, zumal ich auch nicht so genau wußte, für was das RCS überhaupt gut war. Also habe ich daraufhin die drei blauen Telefonbücher (will sagen die mitgelieferte auf den ATARI angepaßte MS-DOS-GEM-Dokumentation) gewälzt, und bin zu der Erkenntnis gekommen, daß dort auch nicht viel drin steht. Mit vereinten Kräften mehrerer Leute haben wir es dann doch geschafft, eine Dialogbox mit dem RCS zu erstellen (was bedeutete, daß uns sogar inzwischen klar geworden war, was der Sinn des Programms eigentlich ist...). Als besonderer Erfolg wurde von uns einige Wochen später die Erkenntnis gefeiert, daß die ‘.H'-Datei (die sogenannte Definitionsdatei) tatsächlich einen Sinn macht und die Programmierung von GEM-Programmen erheblich erleichterte. Das ganze kam uns vor wie ein Adventure. bei dem man ab zu mal wieder etwas Neues entdeckt...

Szenenwechsel

Glücklicherweise arbeiteten immer mehr Leute mit dem ST und benutzten somit auch ausgiebig das Entwicklungspaket mit seinem RCS. Dadurch wurde der Umgang mit dem RCS zur Selbstverständlichkeit. Dennoch hat(te) dieses Programm mehr als nur eine Macke, ganz zu schweigen von der Tatsache, daß jegliche Dokumentation fehlte (nach meiner Kenntnis ist auch heute die Beschreibung in unserem Sonderheft die einzige). In zwischen wurden einige neue Entwicklungspakete mit den unterschiedlichsten Sprachen auf den Markt gebracht, wobei sehr schnell klar war, daß diese Pakete für die professionelle Programmentwicklung selbstverständlich auch ein Resource Construction Set enthalten mußten. Daher kam sehr bald von Megamax ein RCS heraus (das allerdings später in Deutschland vom Kuma RCS abgelöst wurde und daher auch in diesem Vergleichstest nicht aufgeführt ist), und Digital Researchs RCS 2.0 erblickte über irgendwelche dubiose Kanäle das Licht der Welt bis ATARI Deutschland auch diese Version in ihr Entwicklungspaket übernahm. Ein völlig neu gestaltetes RCS kam nach einiger Zeit von Kuma auf den Markt und seit kurzem ist das Wercs von Hisoft dabei, seinen Anspruch auf dem Software-Markt geltend zu machen. Höchste Zeit, dieses wichtige Utility in seinen verschiedenen Erscheinungsformen unter die Lupe zu nehmen. Nebenbei: Ich kann natürlich nicht garantieren, daß das alle Programme dieser Art sind, allerdings sind dies meiner Meinung die bekanntesten Vertreter. Ich möchte dabei so vorgehen, daß ich die RCS einzeln in ihrer Bedienbarkeit und ihrem Funktionenumfang beschreibe und bewerte. Danach möchte ich noch einmal speziell auf die folgenden drei Punkte im direkten Vergleich eingehen: Icon-Editor. Definitionsdatei und die Anleitung. Gehen wir also einfach chronologisch vor. Das erste RCS, das existierte, war das

ATARI RCS, Version 1.x

Sicherlich ist es Sinn und Zweck eines RCS', das Erstellen von Dialogboxen und Menüleisten zu ermöglichen, wobei das Wichtigste eines Programmierhandwerkzeuges in erster Linie die Bedienerfreundlichkeit sein sollte. Auch wenn es auch heute immer wieder Utilities gibt, an denen ein Hacker seine Freude haben würde, stehen Effizienz und leichte Handhabung an erster Stelle. Umso mehr verwundert es einen, daß das ATARI RCS schon damals eine gut durchdachte Handhabung bei der Erstellung der Bäume und Objekte zur Verfügung stellte.

Die Handhabung läßt sich am besten an Bild 1 erkennen. Nach dem Starten des RCS' ist der Bildschirm im wesentlichen in zwei Hälften geteilt (oberer Teil von Bild 1). In der oberen Hälfte findet man die Grundstrukturen der Dialogboxen, Menüleisten und Alertboxen und im unteren Bereich die vom Benutzer erstellten Objekte. Soll nun eine Dialogbox kreiert werden, wird einfach eine neue Dialogbox mit der Maus von oben nach unten gezogen, und schon fragt das RCS nach einem Namen (unter dem diese Dialogbox später im Programm angesprochen werden kann). Danach einen Doppelklick auf das Symbol dieser Dialogbox - und sie Sesam-öffnet sich. Anstelle der Grundstrukturen erscheinen nun in der oberen Box die unterschiedlichen Objekttypen (unterer Teil von Bild 1), die in einer Dialogbox sein können. Auch hier genügt wieder ein einfaches Verschieben eines Objektes vom oberen Fenster in das untere, um dieses Objekt in der Dialogbox unterzubringen. Das Edieren der Objekteigenschaften geschieht, indem man auf das entsprechende Objekt doppelklickt, worauf sich eine (meist große) Box öffnet, in der man alles einstellen kann. Diese Art der Bedienung gefällt mir auch heute noch sehr gut. allerdings mit der folgenden Einschränkung: Immer wenn man von dem oberen Fenster in das untere etwas übernehmen möchte, muß dazu das obere Fenster erst angeklickt werden. Bei etwas umfangreicheren Dialogboxen kann das Hin- und Herschalten zwischen den beiden Fenstern schon etwas nerven. Dennoch gefallt mir ganz besonders, daß die gesamten Eigenschaften eines Objektes nach dem Doppelklick in einer großen Box geändert werden können.

Schon damals bot das RCS einige ganz nützliche Funktionen (siehe Bild 2), die einem das Leben wirklich vereinfachten. So konnte man die Objekte verstecken und versteckte Objekte wieder hervorholen (HIDE/UNHIDE) und auch die Reihenfolge der Objekte durch Sortieren ändern. Dies ist besonders wichtig, wenn man umfangreiche Objektstrukturen erstellt hat. Werden diese nämlich mit ihren beispielsweise 30 Objekten gezeichnet, sieht es nicht gerade schön aus, wenn sie wild durcheinander aufgebaut werden (eine Tatsache, die unbedingt bei großen Drop-Down-Menüs beachtet werden sollte!). Ganz praktisch ist auch die Funktion ‘Flatten’ (Abflachen), mit der man vorher durch ein Vaterobjekt zusammengefaßte Objekte (praktisch, wenn man eine Gruppe von Objekten gleichzeitig verschieben möchte) wieder unabhängig machen kann, indem das Vaterobjekt ohne seine Kinder gelöscht werden kann. Eine Funktion. die recht wichtig ist, wenn man Resourcen erstellen möchte, die auf unterschiedlichen Auflösungen laufen sollen, ist ‘Snap’. Wenn diese Funktion angewählt ist, achtet das RCS darauf, daß die Koordinaten auf Buchstabenbreiten und höhen abgelegt werden, wodurch eine korrekte Umrechnung durch das GEM in der entsprechenden Auflösung sichergestellt ist. Praktisch ist auch, daß man dem RCS in drei Stufen mitteilen kann, wie gut man mit dem Programm und Objektstrukturen umgehen kann (einstellbare Warnstufe). Abhängig von der Einstufung gibt das RCS von sehr vielen Warnungen bei bestimmten Vorgängen bis zu keine Warnung mehr von sich. Die Einstellung ‘Locked’ ist beispielsweise sehr wichtig, wenn man Texte von Resourcen übersetzen möchte, ohne daß dabei die Reihenfolge der Objektnumerierung verändert wird.

Mit ‘Load...’ können Icons, die erstellt worden sind, in das RCS geladen werden. Womit wir bei den negativen Eigenschaften angekommen wären... Wo Licht ist, ist auch Schatten, der besonders in den ersten Versionen besonders groß war. Zunächst einmal muß festgestellt werden, daß das RCS zwar Icons, die sicherlich wichtig für anwenderfreundliche Oberflächen sind, verarbeiten kann, deren Bilder aber im RCS nicht erstellt und auch nicht verändert werden können. In der Anfangszeit gab es noch nicht mal einen (externen) Icon-Editor, so daß das Thema Icon erst einmal vergessen werden konnte. Erst eine ganze Weile später folgte dann ein Icon-Editor, über dessen Qualität ich mich lieber nicht auslassen möchte, so daß zu diesem Zeitpunkt bemerkt wurde, daß das RCS einen dicken Fehler beinhaltete: Das Abspeichern von Resourcen mit Icons klappte nicht, denn dabei stürzte das RCS erst einmal ohne Vorwarnung ab. Glücklicherweise gibt es das RCS heute in der Version 1.4, mit der auch Icons problemlos verarbeitet werden können. Trotzdem ist es ein großes Manko, die Icons außerhalb des RCS ändern zu müssen (die Grunderstellung eines Icons ist, wenn es gut sein soll, recht aufwendig und kann deshalb meines Erachtens ruhig mit einem anderen Programm geschehen).

Alles in allem ist das RCS in der Version 1.4 ein professionelles Programm, mit dem man ohne Probleme arbeiten kann, obgleich es inzwischen sehr günstig zu haben ist. Ich möchte allerdings nicht vergessen zu erwähnen, daß daß die Definitionsdatei (dazu unten mehr) ohne Konvertierung nicht kompatibel zum RCS auf MS-DOS-Rechnern ist.

Bild 2: Auch das RCS 1.4 bietet einiges...
Bild 1: Die Hauptarbeitsbereiche des RCS 1.4

Das RCS 2.x von ATARI...

...ist die weiterentwickelte Version des RCS 1.x und wird inzwischen bei den unterschiedlichsten Entwicklungspaketen (ATARI-Entwicklungspaket für Entwickler, GFA-BASIC, SPC Modula ...) mit ausgeliefert. Bei dieser Version sind nicht nur die Fehler der 1.x-Version ausgebügelt worden, sondern auch neue Funktionen eingebaut, die ich nicht unerwähnt lassen möchte. Dieses RCS ist auch im Entwicklungssystem des MS-DOS-GEM zu finden, so daß Dateien untereinander austauschbar sind (das bezieht sich im wesentlichen auf die Definitionsdatei). Leider kann man es meines Wissens nicht erwerben, so daß es quasi außer Konkurrenz startet.

Zunächst präsentiert sich das RCS 2.1 nach dem Laden so, wie Sie es in Bild 3 erkennen können. Besonders angenehm empfinde ich. daß es nach wie vor Fenster gibt, in dem die edierten Baumstrukturen zu finden, und ein Fenster, in dem die Ausgangsstrukturen vorhanden sind. Sehr von Vorteil ist dabei, daß man diese beiden Fenster nicht mehr aktivieren muß (wie es noch im RCS 1.x der Fall war), sondern einfach einen neuen Baum aus dem unteren Fenster in das obere schiebt ein Fortschritt in der Bedienerfreundlichkeit. Eine neue Art der Bedienung findet man aber, wenn man ein Objekt verändern möchte. Dann nämlich klappen aus den acht links oben befindlichen Icons Pop-Up-Menüs heraus, die die Einstellungen verbergen. Der Vorteil dieser Menüs ist, daß die schon fast überladenen Dialogboxen im RCS 1.x durch kleinere ersetzt werden konnten. Der Nachteil ist, daß diese Einstellungen der Dialogboxen in diesen Pop-Up-Menüs verschwinden. Der Nachteil ist folgender: Wenn Sie beispielsweise mehrere Flags eines Objektes edieren möchten, müssen Sie immer auf das dritte Icon von oben in der rechten Reihe klicken und dann das Flag anklicken, welches geändert wird. Daraufhin schließt sich allerdings das Menü wieder, was bedeutet, daß Sie für die Änderung des nächsten Flags wieder das Icon anklicken müssen, das Flag ändern und so weiter...

Im großen und ganzen sind die Funktionen des RCS 2.x identisch mit denen des RCS 1.x, wobei diese etwas umstrukturiert und auch teilweise ausgelagert wurden. So ist das Kopieren und Löschen eines Objektes auch über die Menüzeile möglich, da diese Funktionen bei der Verwendung der Clipboard- und Papierkorb-Icons in Zusammenhang mit großen Objekten zu Problemen in der Handhabung führen konnte. Außerdem kann man, um sehr große Dialogboxen zu verarbeiten, das linke Fenster mit den Pull-Up-Menüs sowie das untere Fenster mit seinen Baum-Grundstrukturen verschwinden lassen. Ein Pull-Up-Menü möchte ich dennoch nicht missen, da es mit seinen Funktionen die Möglichkeit gibt, Objekte innerhalb anderer Objekte auszurichten. Dabei kann das Objekt links, rechts, ober- und unterbündig sowie mittig bezüglich der Höhe und Breite des Vaterobjektes ausgerichtet werden. Außerdem kann die Größe des Objektes auf die Höhe oder Breite des Vaterobjektes gebracht werden. Ich beschreibe diese Möglichkeiten deshalb, weil ich diese Funktion sehr oft verwende und leider in keinem der anderen RCS wiederfinde. Wenn Sie zu den RCS-Anwendern gehören, werden Sie mir wahrscheinlich rechtgeben, daß das Ausrichten von Objekten nicht selten vorkommt und bei einigen Dialogboxen eine langwierige Arbeit ist, die durch die Funktionen des RCS 2.x sehr erleichtert werden kann.

Einige Zeit, nachdem GEM auf dem ATARI implementiert worden war, gab es eine Veröffentlichung des Digital Research-Mitarbeiters Tim Oren (der übrigens Mitautor des RCS' ist), die sich ‘Professional GEM' nannte. In einer der Folgen wurde erwähnt, daß nicht alle Bits innerhalb der Objektstruktur tatsächlich auch von GEM genutzt und - viel besser noch - ignoriert würden. Dadurch ist es dem Anwender möglich, an dieser Stelle eigene Informationen unterzubringen. Um diese Möglichkeit zu nutzen, müßte es aber ein RCS geben, in dem man diese Bits schon bei der Erstellung der Resourcen setzen kann. Dies ist mit dem RCS 2.x möglich geworden, da jedem Objekt ein sogenannter EXTENDED OBTYPE hinzugefügt werden kann. Diese Zahl wird in das obere Byte des ob_type eines Objektes geschrieben und kann später innerhalb des Programms ausgewertet werden. Leider ist dies die einzige Möglichkeit, da es, wie das K-Resource zeigt, noch mehr Möglichkeiten gibt, einem Objekt an ungenutzten Stellen Informationen beizugeben.

Äußerst positiv ist mir aufgefallen, daß alle Funktionen der Drop-Down-Menüs (ok, bis auf eine, und zwar ‘Remove parent' was dem alten 'Flatten’ entspricht) durch die Tastatur anwählbar sind. Leider schließt das die Funktionen der meines Erachtens ganz interessanten aber letztendlich etwas umständlichen Pull-Up-Menüs nicht mit ein. Zusammengefaßt bietet das RCS 2.x gegenüber dem 1.x die einfachere Handhabung bezüglich der Fenster sowie die praktischen Funktionen zum Ausrichten eines Objektes, wohingegen das Ändern eines Objektes mit Hilfe der Pull-Up-Menüs teilweise etwas nerven kann. Die Möglichkeit ‘extended ob_types’ zu nutzen, spricht auch dafür, von RCS 1.x auf 2.x umzusteigen. Die Kompatibilität der DFN Datei zu der MS-DOS-Version ist sicherlich als Vorteil für die zu sehen, die mit beiden Betriebssystem arbeiten wollen oder müssen.

Bild 3: Der Arbeitsbildschirm des RCS 2.1
Bild 4: Viele Funktionen gut geordnet
Bild 6: Die umfangreiche Menüleiste von Wercs
Bild 5: Ein Teil der Auswahlmöglichkeiten von K-Resource 2

Das K-Resource 2

Zwei Dinge zeigt uns der Name dieses Programms: Erstens ist der Name Resource Construction Set von Digital Research geschützt und zweitens handelt es sich offensichtlich um die zweite Version des Programms, die unter anderem deshalb nötig wurde, weil das alte Programm auf dem Blitter-TOS nicht lief.

Lädt man das K-Resource, befindet man sich auf einer Desktop-ähnlichen Bedieneroberfläche, die dadurch, daß sie sehr bekannt wirkt, sofort zum Arbeiten einlädt. Eine nette Tatsache ist, daß das K-Resource 2 die Disk-Icons und den Papierkorb genauso postiert, wie Sie sie auf dem Desktop liegen haben [kleine Anmerkung: Es benutzt vermutlich die Einstellungen, die im Desktop.Inf gespeichert sind - wahrscheinlich über Shel_get()]. Auf dieser Oberfläche ist es möglich, mehrere Inhaltsverzeichnisfenster zu öffnen, zwischen denen Dateien hin- und herkopiert werden können. Soll eine RSC-Datei bearbeitet werden, wird einfach die entsprechende Datei von dem Directory-Fenster auf die K-Resource-Desktop-Fläche gezogen und schon öffnet sich ein Fenster, in dem nun nicht mehr Dateien, sondern Baumstrukturen zu finden sind. Ein sehr großer Vorteil bei diesem Konzept ist, daß es dadurch auch möglich ist, mehrere RSC-Dateien gleichzeitig zu öffnen, zu bearbeiten und zwischen ihnen auch Baumstrukturen auszutauschen. Dadurch können beispielsweise Objekte, die oft benötigt werden und mit viel Mühe erstellt worden sind (beispielsweise Icons), in einer speziellen Datei gesammelt und später als Baumstruktur oder auch nur als Objekt wieder hinzugeladen werden.

Sicherlich ist K-Resource als das erste wirklich vollständige RCS anzusehen, da es zum ersten Mal auch einen Icon-Editor integriert bekommen hat (siehe unten). Im wesentlichen enthält das K-Resource allerdings die gleichen Funktionen wie das RCS von Digital Research, nur mit dem Unterschied, daß sie mehr von der Menüzeile auf das Desktop verlegt worden sind. Daher ist es das RCS für den Mausliebhaber. Praktisch ist auch, daß die Objektnummer des Objektes, das unter der Maus zu finden ist, immer sofort in der Menüzeile (ein seltsamer Ort...) eingeblendet wird, wodurch man sicherstellen kann, daß die Objekte in einer Reihenfolge liegen, wie man sie auch wirklich haben möchte. Eine schöne Art der Handhabung sind Menüs, die am Objekt erscheinen, wenn man dieses anklickt (siehe Bild 5 rechts oben). Damit ist die Wahl der möglichen Funktionen sehr gut dargestellt und vom Benutzer anwählbar - kein lästiges Herumsuchen nach 'Was kann man nun mit diesem Objekt tun'-Funktionen innerhalb der Menüleiste. Meines Erachtens ist damit der viel strapazierte Begriff ‘Information hiding' in bezug auf die Bedienerfreundlichkeit relativ gut in die Tat umgesetzt worden. Man sollte sich also nicht durch die etwas kleine Menüzeile täuschen lassen.

Glücklicherweise findet man die schönen, großen, vom RCS 1.x bekannten Dialogboxen, in denen man alle Einstellungen ohne Drop-Down-Menüs machen kann, im K-Resource 2 wieder. Hinzugekommen sind die (beim RCS 2.x) erwähnten ‘extended obtypes', aber auch 'extended flags' und ein Feld für 'extended Status', wobei Flags, wie es sich so gehört, tatsächlich bitweise gesetzt werden können. Alle diese Werte, die im K-Resource 2 gesetzt werden, können später im Resource in den High-bytes der Objektstruktur Elemente ob_type, ob_flags und ob_state wiedergefunden und verarbeitet werden, woraus sich eine hohe Flexibilität für den Anwender ergibt. Als erstes RCS bietet das K-Resource 2 auch die Möglichkeit, eine Baumstruktur einmal auszuprobieren, um beispielsweise zu erkennen, ob alle Objekte (in der Art) selektierbar sind (wie man es sich vorgestellt hat). Angenehm fiel mir dabei auf, daß hierbei vorher geprüft wird, ob überhaupt ein Ausgang für diese Dialogbox besieht, da ein fehlender Ausgang zum Hängenbleiben in der Testfunktion führen würde (einen solchen Test gibt es bei Wercs auch, das ebenso vorher prüft, ob ein Ausgang vorhanden ist).

Insgesamt stellt sich dieses Resource Construction Set als komplettes System dar, das zwar noch kleine Wünsche offen läßt (siehe auch unten über den Icon-Editor sowie Definitionsdatei und Anleitung ), das aber durch seine Bedienerfreundlichkeit gestattet, relativ schnell Resourcen zu erstellen.

Hi-Soft WERCS...

...das ursprünglich für das FTL Modula gedacht war, welches in der ST-Computer 3/90 getestet worden ist, gibt es seit ein paar Monaten über CCD auch einzeln zu kaufen. Dies erklärt wahrscheinlich auch, warum es (noch) nicht ganz so bekannt ist wie die anderen RCS.

Das Wercs, dessen Name mich seltsamerweise an Arbeit erinnert (Works...), ist angetreten, den Kampf gegen das arbeitsintensive Gestalten der Resourcen zu bestehen. Nach dem Laden findet man zunächst einmal nur ein leeres Fenster und eine riesige Menüzeile vor. Im Gegensatz zum K-Resource 2 ist es nicht möglich, mehr als eine Resource-Datei zu bearbeiten. Nur durch einen Trick über Importieren und Einfügen kann man das erste Objekt innerhalb des ersten Baumes einer zweiten Resource-Datei (am besten den Teil des Satzes noch einmal langsam lesen) in die in der Arbeit befindliche Datei importieren. Bedenkt man, daß schon das RCS von Digital Research eine Funktion zum Einfügen anderer Resourcen hat, so finde ich es etwas bedauerlich, daß dies in Wercs nicht vorhanden ist. Ich gebe allerdings zu, daß ich diese Funktion erst ab dem Moment vermißte, als ich versucht habe, Icons hinzuzuladen - solange hatte ich die Merge-Funktion im RCS nie bewußt wahrgenommen.

Wercs bietet an Funktionen (fast) alles, was man sich wünschen kann. Eine Tatsache, die man an der Unmenge von Menüeinträgen auch schon erahnen kann. Die Vermutung, daß Wercs eine andere Konzeption bezüglich der Bedienung im Vergleich zum K-Resource 2 verfolgt, ist auch sehr schnell erkennbar. Während K-Resource die entsprechenden Funktionen erst beim Anklicken des Objektes als Untermenü hervorbringt und später eventuell noch eine Dialogbox als weiteres Auswahlmenü, so setzt Wercs auf eine Menüleiste, deren Drop-Down-Menüs abhängig von dem in Bearbeitung befindlichen Objekt anwählbar sind. Nachteilig an Drop-Down-Menüs (oder auch Pull-Up-Menüs) ist, daß mehrfache Einstellungen. wie sie beispielsweise beim Ändern des Objektstatus' oder der Objektflags Vorkommen, ein wiederholtes Anwählen der Drop-Down-Menüs erfordern. Dennoch braucht man dies bei Wercs nicht unbedingt, da jeder(!) Funktionseintrag in den Menüleisten von Wercs über die Tastatur zu bedienen ist. Leider fehlt eine Übersicht der Menüleisten (einer der wirklich wenigen Kritikpunkte an der sonst recht guten Anleitung), wie ich sie Ihnen in Bild 6 dargestellt habe. Hat man eine solche Übersicht neben dem Rechner hängen, kann man über Tastatur sehr schnell alle Eigenschaften einstellen und bei Bedarf noch einmal in der Menüleiste nachschauen, wie das Objekt momentan definiert ist. Wenn man also einmal die gebräuchlichsten Tastenfunktionen parat hat, ist sicher ein sehr schnelles Arbeiten mit Wercs möglich.

Eine Funktion, die ich in den anderen RCS noch nicht gefunden habe, ist das Suchen nach einem definierten Namen oder Index eines Objekts oder einem Text innerhalb eines Text-/String-Objekttyps. Bei größeren Werken kann es schon von Vorteil sein, mal zu schauen, wo welches Objekt mit welchem Namen oder welcher Nummer zu finden ist, oder ob man einen bestimmten Text schon einmal benutzt hat, oder man weiß eventuell nicht mehr, wo das Objekt ist, aber daß in ihm ein bestimmter Text vorkommt...Leider fehlt in Wercs wie auch im K-Resource 2 die Möglichkeit, ein Objekt ausrichten (zentrieren etc.) zu können.

Wie man es seit dem RCS 2.x gewohnt ist, gibt es auch die Möglichkeit, einem Objekt einen ‘extended obtype’ zu geben. Leider findet man die im K-Resource zu findenden ‘extended ob_flags’ und 'extended ob_states' nicht (wobei ich mir zugegebenermaßen nicht ganz sicher bin, ob die High-Bytes von ob_state und ob_flags von Digital Research offiziell als verwendbar freigegeben worden sind und eine Veränderung dieser Bits nicht eventuell bei späteren Versionen des GEM zu Problemen führen könnte). Bei der Anzahl der Objekttypen kann man sich allerdings nicht beschweren: Es ist sogar der Objekttyp PROGDEF vorhanden, der es ermöglicht, an dieser Stelle später im Programm eigene Routinen ausführen zu lassen, und der auch eine eigene Art der Darstellung in Wercs besitzt (man sollte nur darauf achten, dieses Objekt später im Programm auch zu vervollständigen, das heißt, auch einen Einsprung in eine Routine mit unterzubringen). Als besonderes EXTRA (so heißt der Menüpunkt) ist das direkte Verändern durch Zahleneingabe der Objektkoordinaten und Größe sowie die Nummer des Nachfolgers hinzugekommen, wodurch eine Sortierreihenfolge manuell festlegbar ist. Das Sortieren, welches wie bei allen anderen RCS vorhanden ist, möchte ich erwähnen, weil man in Wercs das Sortieren nicht nur nach der Objektposition, sondern auch alphabetisch (bezüglich des Inhalts von Strings) ausführen kann (das Sortieren bezieht sich natürlich nur auf den Objektindex, der für die Reihenfolge des Bildschirmaufbaus wichtig ist, und bewirkt keine Veränderung der Objektkoordinaten).

Zusätzlich zu Wercs befinden sich auf der Diskette noch zwei kleine Programme. Mit dem einen lassen sich die Definitionsdateien anderer Resourcen (siehe unten) in das Wercs-eigene Format umsetzen. Mit dem anderen Programm WIMAGE ist es möglich, einen Bildausschnitt mit einer maximalen Größe von 128x 128 Pixel aus einem Farb- oder Monochrombild auszuschneiden und in einen Bit-Block oder ein Icon umzusetzen, der/das in das Resource in Wercs über Importiere/Einfügen geladen werden kann. Für alle Wercs-Anwender und sonstige Neugierige sei hier angemerkt, daß die Ausgabedatei von WIMAGE nichts anderes als eine kleine Resource-Datei ist, die als erstes Objekt eine Box und als zweites den Bit-Block enthält!

Das Wercs ist sicherlich kein RCS, das nur für das FTL-Modula seine Berechtigung hat, sondern es kann sich durchaus mit den anderen RCS messen. Positiv fallen der große Funktionsumfang und die umfangreiche Tastaturbedienung auf.

Bild 7: Ein versuchter Icon-Editor im K-Resource 2
Bild 8: Mit dem Icon-Editor von Wercs läßt sich arbeiten

Ein trauriges Thema...

...ist der Icon-Editor. Bedenkt man, daß sich das GEM nicht nur durch seine tollen Fensterchen und Menüleisten auszeichnet, sondern auch durch seine Piktogramme (angelsächsisch Icons), so ist es als peinlich zu erachten, daß es ATARI oder besser gesagt Digital Research bis heute nicht geschafft hat. ein Resource Construction Set herauszubringen, daß einen Icon-Editor integriert hat. Soweit mir bekannt ist, liefert die Firma ATARI bei ihrem Entwicklungspaket ein Programm mit, das sich Icon-Editor schimpft, über das ich aber lieber kein Wort verlieren möchte, da es eher zum Abgewöhnen ist (ich entschuldige mich für die harten Worte, aber ein Programm, das einem die Arbeit erleichtern soll, mit dem man sich aber eher herumquält, kann ich nicht akzeptieren).

Glücklicherweise beinhaltete das K-Resource 2 einen Icon-Editor, der annähernd seinen Namen verdient (Bild 7). Dennoch finde ich die Arbeitsgeschwindigkeit dieser Zugabe nicht gerade berauschend und die Methode die Daten und Maske in einem Bild bearbeiten zu müssen, nicht gerade richtungsweisend (erkennen Sie in Bild 7 die schwarz gezeichneten Daten und die grau dargestellte Maske?). Leider wurde die Wichtigkeit eines guten Icon-Editors im K-Resource meines Erachtens unterschätzt, so daß man (nach Aussagen auch anderer Anwender) sich gerne verleiten läßt, entweder das Icon nicht ganz so aufwendig zu gestalten oder es eventuell sogar ganz wegzulassen. Schon besser ist die Implementierung des Icon-Editors in Wercs (Bild 8). dessen Geschwindigkeit annehmbar und mit dem es auch möglich ist, die Maske und die Daten getrennt (sogar in unterschiedlicher Größendarstellung) zu bearbeiten. Selbst eine Funktion zum Zeichnen einer Linie oder das Spiegeln der Daten (allerdings nur bezogen auf das ganze Icon) ist vorhanden. Einige Leser werden wissen, daß ich den auf einer Sonderdisk erhältlichen Icon-Design geschrieben habe (mit dem es möglich ist, komfortabel außerhalb eines RCS' Icons zu erstellen und in alle der vier RCS zu laden) und diesen damit hochspielen möchte. Mir ist klar, daß ein so umfangreiches Programm wie Icon-Design nicht unbedingt in diesem Umfang in einem Resource Construction Set Platz finden muß. allerdings ärgere ich mich dennoch darüber, daß bestimmte Funktionen (wie hier ein Icon-Editor) durch ihre halbherzige Implementierung eher zum Nichtbenutzen als zum Benutzen verführen. Weder K-Resource noch Wercs bieten einen offiziellen Weg, Icons nachzuladen oder abzuspeichern (die Digital Research RCS können Icons laden). Beim K-Resource geht es nur dadurch, daß man eine zweite Resource Datei lädt, in der man Icons gesammelt hat. und in Wercs geht es über den Trick des Importierens/Einfügens, vorausgesetzt das Icon befindet sich an zweiter Stelle in einer Resource-Datei. CCD hat allerdings in einem Gespräch erwähnt, daß sie wahrscheinlich das ICON-DESIGN-Format zum Laden und Speichern von Icons in WERCS implementieren werden (nachfragen!).

Die Definitionsdateien

Wer von Ihnen schon einmal mit einem Resource Construction Set gearbeitet hat. weiß, daß man jedem Objekt einen Namen geben kann. Diese Namen und die Art der Baumstruktur werden allerdings nicht mit in der Resource-(RSC)-Datei. sondern in einer speziellen Datei abgespeichert. Beim RCS 1.x hat sie die Namenserweiterung DEF, die beim RCS 2.x in DFN geändert wurde, da DEF schon in Modula als Include-Dateierweiterung vergeben war und eine Änderung bezüglich der MS-DOS vorgenommen wurde (prinzipiell werden nur die Hi- und Lo-Byte-Zeiger innerhalb der Datei umgedreht). Das erste Kuma-Resource kam scheinbar vor dem RCS 2.x heraus und hat auch aus Modula-Gründen die DEF-Erweiterung in RSD umbenannt, wobei eine RCS Lx-Datei kompatibel zu einer RSD-Datei ist. Wercs wiederum hat wieder ein anderes Dateiformat. das sich nach außen hin durch die Erweiterung HRD auszeichnet. Verwirrt genug? Sicherlich: Die eigentliche Resource-Datei, die das GEM benötigt, können alle vier Programme lesen, aber die Definitionsdateien nicht. Netterweise liefern ATARI (für RCS 1.x auf RCS 2.x) und HI Soft (für RCS 1.x, RCS 2.x und K-Resource auf Wercs) Programme, mit denen man Fremdformate in das eigene Umwandeln kann, aber keines dieser Programme kann dies wieder rückgängig machen - man verschließt sich also immer den Weg zurück. Wer hat schon Lust, wenn er von einem RCS auf das andere wechselt, alle hundertfünfzig Namen einer Resource-Datei neu einzugeben (das Angeben der Baumart konnte man ja noch verschmerzen)? Wahrscheinlich werde ich, um diese Misere zu beheben, in einer der nächsten ST-Ecken ein Konvertierungsprogramm für alle drei Formate vorstellen (DEF->DFN und DFN->DEF funktionieren schon), das man dann auch auf der Icon-Design-Disk finden wird.

Anleitung

Leider ist das ein Thema, das allzu oft von Software-Hausern sehr ‘stiefmütterlich' gehandhabt wird. So gibt es keine offizielle Anleitung zum RCS 1.x (nur eine im Sonderheft der ST-Computer), und auch das RCS 2.x verfügt auf dem ATARI über keine Anleitung, die von ATARI oder Digital Research erstellt worden ist. (Vielleicht sollte man mal die Beschreibung des GEM-Entwicklungssystems auf dem IBM danach durchstöbern.) Soweit mir bekannt ist, wird aber dem SPC Modula, welches, wie erwähnt, das RCS 2.x enthält, eine Anleitung beigelegt, die ich aber leider nicht bewerten kann, da ich sie nicht besitze. Dennoch möchte ich ein paar Worte über die Anleitungen von K-Resource 2 und Wercs verlieren, da diese immerhin als eigenständige Programme verkauft werden. Es sei noch vorausgeschickt, daß ich keine Einführung in die GEM-AES-Programmierung erwarte.

Die Anleitung des K-Resource 2 ist mit seinen 47 Seiten, die Inhaltsverzeichnis, Index und ein Listing beinhalten, relativ dünn, was aber durch das dicke, kartonartige Papier wieder etwas ausgeglichen wird... leider sind auch einige der Bilder nicht besonders gut zu erkennen. Dennoch wird die Handhabung des Programms zufriedenstellend beschrieben, so daß ein Arbeiten nach dem Lesen der Beschreibung sicherlich möglich ist, zumal das K-Resource 2 auch relativ leicht zu bedienen ist. Gut finde ich auch, daß das Format der Definitionsdatei im Anhang vorhanden ist, wodurch eine Anpassung an andere For mate letztendlich möglich wird. Wenn auch die Einleitung zurecht feststellt, daß man ‘in diesem Handbuch keine Programmieranleitung für das AES geben könne’, so ist meine Meinung, daß auf Objektstrukturen viel zu wenig eingegangen wird (praktisch gar nicht). Das einfache Mitliefern eines kurzen Beispielprogramms bei einem Programm, das immerhin 129,- DM kostet, finde ich etwas wenig. Wer allerdings sowieso die (hinten im Anhang aufgeführte) Literatur besitzt, sollte sich davon nicht abhalten lassen.

Schon besser hat mir die Anleitung von Wercs gefallen, die sich beispielhaft durch solche Tabellen wie die in Bild 9 auszeichnet (veröffentlicht mit freundlicher Genehmigung von CCD). Außerdem gibt sie meines Erachtens eine insofern ausreichende Einführung in Objektstrukturen, daß wenigstens ein einigermaßen geübter Programmierer sich darunter etwas vorstellen kann. Die Beschreibung des Programms ist im allgemeinen gut (nur die zusammengehörenden Funktionen Einfügen und Importieren sollten in Zukunft etwas ausführlicher dargestellt werden). Auch die im Anhang befindliche Auflistung der Tastaturbefehle sowie des HRD Dateiformats sind ganz nützlich. Inhaltsverzeichnis und Index sind zufriedenstellend, wobei mir ein Index kaum zu lang sein kann.

Resümee

Nachdem ich nun mehrere Wochen mit allen vier Resource Construction Sets gearbeitet habe und ich mich nun entscheiden müßte, welches ich mir kaufen würde, könnte ich keine einfache Antwort geben (ich weiß, ich mag auch keine Tests, in denen man keine echte Entscheidungshilfe bekommt). Zunächst einmal fällt das RCS 2.x als Kauf weg, da es nur in Zusammenhang mit Entwicklungssystemen erhältlich ist. Bleiben noch das ATARI RCS 1.x, erhältlich als Sonderdisk bei MAXON, das K-Resource 2, zu erwerben bei Knupe, und das Wercs von Hi-Soft, welches in Deutschland von CCD vertrieben wird.

Das ATARI RCS 1.x ist für sein Alter und seinen Preis sicherlich noch gut in Schuß. Wenn es auch nicht gerade jeden Komfort bietet, so hat man (inklusive eines Icon-Editors für 15 DM) für 30 DM sicherlich ein System, mit dem man ohne weiteres arbeiten kann (ich habe jahrelang ohne Probleme damit gearbeitet). Das Preis/ Leistungsverhältnis ist recht gut. Nachteilig ist. daß es erstens nicht mehr weiterentwickelt wird (die Ablösung 2.x gibt es wie gesagt nicht einzeln zu kaufen) und zweitens (außer der Sonderheft-Anleitung) keine Anleitung vorhanden ist.

Das K-Resource 2 ist von der Mausbedienung sehr komfortabel und auch die Einführung der objektanhängigen Pull-up-Menüs ist angenehm. Dennoch möchte ich als negative Punkte die etwas schlechtere Anleitung, den meines Erachtens überarbeitungsbedürftigen Icon-Editor und nicht zuletzt den höchsten Preis innerhalb der getesteten Resource Construction Sets anführen.

Das Wercs hat mich ein wenig überrascht, da es (jedenfalls mir) relativ unbekannt war und dennoch ganz gut mit dem K-Resource 2 mithält. Die Bedienung des Wercs ist nicht ganz so (Maus- und Fenster-)komfortabel wie die des K-Resource 2, was aber durch die umfangreiche Tastenbedienung wieder etwas ausgeglichen wird. Mit seinem Preis von 99,- DM ist es sicherlich eine Alternative zum K-Resource 2, wobei man abwägen muß, ob man eher ein Tastenbedienung mit vielen Zusatzfunktionen wie in Wercs haben möchte, wobei nach Auskunft von CCD voraussichtlich das Zentrieren von Objekten, wie es in RCS 2.x zu finden ist, implementiert wird (nachfragen!), oder einem das Fensterln und Mausen mehr zusagt, und man Wert auf die ‘extended’ Bits legt.

Alles in allem gibt es inzwischen vier Resource Construction Sets, mit denen man recht gut arbeiten kann. Zur leichteren Kaufentscheidung habe ich Ihnen nochmal eine Tabelle zusammengestellt, in der ich versucht habe, einzelne Punkte innerhalb einer Skala von 1 bis 10 zu bewerten. Natürlich ist eine solche Tabelle subjektiv. Wenn Sie aber abwägen, wie wichtig oder unwichtig Ihnen ein Tabelleneintrag ist, kann diese Tabelle sicherlich trotzdem eine Hilfe sein.

SH

Vergleichstabelle der vier Resource Construction Sets

  RCS 1.x RCS 2.x K-Resource Wercs
Auflösung L/M/H L/M/H M/H L/M/H
Großbildschirm ja ja ja ja
fehlende Objekttypen ProgDef Free Strings Free Images extended Bits extended Obtype ProgDef extended Bits ProgDef extended Bits
Wertung 5 7 10 8
Kompatibilität entfällt aufwärts zu RCS x.x aufwärts
Definitionsdatei - 5 6 8
Sprachen- Ausgabe C/Pascal C/Pascal/ BASIC2 C/Pascal C/Pascal
Definitionsdatei C-Code Modula' BASIC C-Code 1 Modula/ Fortran Modula/ Fortran
Funktionsvielfalt 5 7 8 10
Testfunktion Nein Nein Ja Ja
Icon-Editor - - 4 7
Laden von Icons Ja4 Ja4 Nein4 Nein4
einstellbare Warnstufe Ja Ja Ja Ja
Beispiele - - 8 8
Dokumentation - ? 46 Seiten 5 95 Seiten 8
Support Nein* Ja6 schriftlich Ja
Zusatzprogramme STCreate STCreate DEF2DFN - WIMAGE WCONVERT
Preis 15, 3 129.- 99,-
Bezugsquelle A i B C

1 C-Code, der die Resource-Struktur enthält, die geändert werden und in Zusammenhang mit STCreate In RSC-Datei umgesetzt werden kann.

2 in Spezial-Version bei GFA-BASIC mitgeliefert

3 nicht einzeln erhältlich

4 mit Icon-Design möglich

5 über Hot-Line Donnerstags von 14-17 Uhr der ST-Computer-Redaktion

6 In Zusammenhang mit Support der jeweiligen Programmiersprache

A: MAXON Computer GmbH Industriestr 26 6236 Eschborn

B: Gerhard Knupe GmbH A Co KG Güntherstr. 75 4600 Dortmund

C CCD Burgstr. 9 6228 Eltville Tel 06123 1636

Bild 9: Eine Tabelle aus der Wercs-Anleitung stellt den Zusammenhang zwischen Objekttyp und Auswirkung dar.



Aus: ST-Computer 06 / 1990, Seite 20

Links

Copyright-Bestimmungen: siehe Über diese Seite