Resource-Konverter: Doppelt hält besser

GEM-Resourcen können bei der Parallelentwicklung vom Atari zum PC nicht einfach übernommen werden. »Desktop« verspricht Abhilfe.

Da viele Atarianer gezwungen sind, auf mehreren Computersystemen zu arbeiten, entwickeln manche ihre Programme parallel auf zwei Rechnerwelten. Mit GFA-Basic fällt dies besonders leicht, da das komplette Programm fast identisch auf »Kompatible« übernommen werden kann. Aber der gleiche Compiler macht noch nicht die grundlegenden Unterschiede der Rechnerfamilien wett. Auch wenn ein Basic-Quelltext prinzipiell übernommen werden kann, so schwierig ist es, die Resource eines Resource-Construction-Set auf einen anderen Rechner zu übertragen. Diese Datei liegt normalerweise nicht als normaler ASCII-Text vor, sondern jedes RSC benutzt zum Speichern ein spezielles Binärformat. Dieses unterscheidet sich zwar nicht erheblich von dem unter dem PC benutzten Format, so daß eigentlich eine Einbindung ohne weiteres möglich wäre. Jedoch funktioniert das Programm inkl. der Resource nur unter PC-GEM. Die Benutzung dieser nicht so bekannten Oberfläche ist aber nicht erstrebenswert, da man sie so ähnlich wie Windows starten und installieren muß. Daher bietet die Firma Watersoft einen entsprechenden Konstrukteur für Rcs-Dateien inkl. Konverter an. Natürlich sind diese Programme nicht in der Lage, ein Atari-Programm vollständig für den PC lauffähig zu konvertieren. Aber sie erleichtern die Arbeit ungemein, weil sie viele fertig programmierte Routinen zur Verfügung stellen, die z. B. die Verwaltung von Fenstern in die Verwaltung von Objekten einbinden.

Bei der Erstellung der Re-sourcen kann man entweder auf sein Resource-Contruction-Set auf dem Atari zurückgreifen und das entstandene File konvertieren oder mit dem mitgelieferten Programm »Desktop« auf dem PC Dialoge entwerfen. Ein Problem, das gerade auf dem PC immer wieder zu finden ist, stellen die unterschiedlichen Grafikkarten mit ihren verschiedenen Auflösungen dar. Gerade bei der Verwendung von Bildern entstehen daher erhebliche Probleme. Aus diesem Grund wird ein spezieller Bildeditor mitgeliefert, der dem Entwurf von Images oder Icons dient. Er ist in der Lage, PCX-Bilder zu laden und zu wandeln. Die angefertigten Bilder lädt das Desktop problemlos und fügt es an die entsprechende Stelle im Dialog ein. Neben dem üblichen Zeichnen von Objekten wie Texten, Buttons und Edits beherrscht es die Verarbeitung von Popup-Menüs. Zwar können diese nur in einem Dialog eingesetzt werden, so daß ein Aufruf durch Klicken auf den Desktophintergrund nicht möglich ist. Aber dies tut der Verwendung keinen Abbruch, denn Desktop meldet diesen Klick auf das Fenster mit der Nummer Null und somit ist es theoretisch möglich, den Dialoghandler einfach mit dem entsprechenden Objekt aufzurufen. Ein eventuell entstandener Redraw übernimmt Desktop vollautomatisch. Damit steht der Verwendung von Popups wie auf dem Atari-Rechner nichts mehr im Wege.

New Redraw

Überhaupt erledigt das Ergänzungstool »desk.gfa« fast vollständig den kompletten Redraw. Dabei ist es unerheblich, ob es sich um Fenster, Dialoge oder Menüleisten handelt. Aufgrund einer gewissen objektorientierten Programmierung ist beim Redraw jeweils das eigentliche Programm oder das im Programm eingebundene »desk« zuständig. Dabei stehen dem Programmierer mächtige Routinen zur Verfügung, die eine einfache Steuerung der Abläufe ermöglichen. Natürlich kann man im nachhinein die Objekte jederzeit mit speziellen Hilfsprozeduren und -funk-tionen verändern. So erzeugt z. B. input$(...) eine Box, die neben einem Bild und einem Aufrufstring auch eine Editmaske mit gültigen Eingabezeichen als Aufrufparmeter verlangt und als Rückgabewert die Eingabe besitzt. Unter anderem findet man hier auch die schon vom Atari-Rechner bekannte Funktion rsrc_load(). Natürlich muß diese Routine noch ein bißchen mehr können als ihr Atari-Pendant; so werden von ihr an jede neue Grafikkarte Dialog und Bilder angepaßt. Neben dem bekannten form_do() gibt es das form_peek(). Mit ihr kann man mehrere Dialogboxen, zusätzliche Fenster oder die Menüleiste scheinbar gleichzeit kontrollieren. Dabei werden erst die entsprechenden Dialoge gezeichnet, mit form_start() initialisiert und in einer Endlosschleife dauernd aufgerufen (siehe Listing). Eine entsprechende Verarbeitung muß das Hauptprogramm zur Verfügung stellen.

Durchstarten

Zur Initialisierung des Programms steht die Funktion w_init zur Verfügung, die beim ersten Start auf einem PC alle wichtigen Parameter setzt. Sie überprüft die Konfiguration der Grafikkarte und stellt den entsprechenden Modus ein. Normalerweise bestimmt diese Funktion, in welchen Grafikmodus gearbeitet wird, jedoch kann man in einer Datei vorher festlegen, welcher Modus (z. B. EGA, VGA, SVGA) mit welcher Zeichenhöhe benutzt werden soll. Weiterhin lädt sie eine Datei »desktop.rsc«, in der das normale Resource steht. Warum der Weg über zusätzliche Dateien beschritten wird, bleibt allerdings unverständlich. Man muß doch nicht die Uneigenheit im PC-Bereich fördern. Reservierte Prozeduren und Variablen hätten sicherlich keine Einschränkung bedeutet.

Apropos Einschränkungen: Einige vom Atari gewohnten GEM-Routinen werden nicht unterstützt. So gibt es kein form_dial, form_error, form_keybd, formjbutton, objc_add, objc_delete, objc_order und objc_edit. Von den graf...-Routinen existiert nur graf_watchbox. Normalerweise ist dies nicht als Nachteil zu werten, zumal es nicht die wichtigsten sind. Allerdings ist man die Benutzung dieser Routinen vom Atari gewohnt und somit bedeutet eine parallele Programmierung die Überarbeitung entsprechender Programmteile.

Das Handbuch, das in Wirklichkeit eher ein 45-Seiten-Heft ist, gestaltet sich kurz und an manchen Stellen zu knapp. Für den Atari-Anwender reicht dieses sicherlich insoweit aus, indem er nur das vom Atari Gelernte auf dem PC anwenden möchte, Anderenfalls handelt es sich um eine von Rechtschreibfehlern gespickte Magerkost, in der hauptsächlich die neuen Routinen beschrieben werden. Zwar existiert zu jeder Routine ein Beispiel und es sind auch genügend Muster auf der mitgelieferten Diskette vorhanden, jedoch helfen sie beim grundlegenden Einstieg in die Programmierung von Resourcen nur wenig. Nicht einmal auf entsprechende weiterführende oder für den Einstieg notwendige Literatur wird verwiesen. Eine Hotline ist im Heft auch nicht angegeben, so daß der PC-Anfänger völlig im Stich gelassen wird.

Insgesamt ist Desktop für eine parallele Entwicklung vom Atari-GfA-Basic zum PC eine hilfreiche Unterstützung, da alle notwendigen vom Atari bekannten Routinen zur Verfügung stehen. Jedoch wird der Nur-PC-Besitzer beim »Handbuch« arg im Stich gelassen. Ein gutes Produkt mit unangenehmen Nebengeschmack. (thl)

Deutschland: WATER SOFT, J. Koch, Am Pfingstborn 9, 55437 Ober-Hilbersheim, ; Ausland: GFA-Systemtechnik, Düsseldorf

‘ Box 1 zeichnen void @objc_draw(box_l%,0,300 0,0,sys_x%,sys_y%) ‘ Box 2 zeichnen void @objc_draw(box_2%,0,100,0,0,sys_x%,sys_y%) ‘ Box initialisieren edit! = @form_start(box_l%,0) ‘ Endlosschleife do ‘ Menüleiste und Fenster PEEKJEVENT

‘ Kontrolle von Box 1 EXIT IF @form_peek(box_l%, edit!) »= 0 ‘ Kontrolle von Box 2

Pseudoparallele Dialogprogrammierung

WERTUNG

Desktop

Hersteller: Watersoft
Preis: 178 Mark

Stärken: eigenes RCS, eigenes Windowhandling, fast vollst. Redraw, Resource-Konverter, pseudoparalleles Dialoghandling

Schwächen: Handbuch, fehlende GEM-Dialogroutinen

Fazit: zum Konvertieren eine sehr nützliche Hilfe