PRAM - Verdeckte Ermittlungen
Die Dialogroutinen im TOS haben einen nervraubenden Fehler: sie werten das »HIDETREE«-Bit im Dialogbaum nicht korrekt aus.
Die Dialogroutinen des Atari-Betriebssystems sind wahrscheinlich die meistgepatchten überhaupt. Schon bald nachdem die ersten alternativen Dialogroutinen, hauptsächlich durch das Programmpaket »GEMINI«, für einen erheblich verbesserten Bedienungskomfort sorgten, begannen diverse Programmierer, ihren Werken eigene Dialoghandler aufzupfropfen. Dabei scheint sich teilweise die Auffassung durchzusetzen, daß eine gelungene Benutzerführung ein ansonsten unbrauchbares Programm retten könne. Wir halten dem jedoch entgegen: Zwar zählt der Bedienungskomfort eines Programmes zu den zeitintensivsten Beschäftigungen beim Entwurf eines neuen Systems, ein ansonsten unbrauchbares Gesamtkonzept werden sie jedoch kaum retten.
Wie dem auch sei: Heute pflastern eine Vielfalt mehr oder weniger gelungener Alternativdialoge die Landschaft. Begonnen beim Klassiker »Flydials« über »KeyDials«, »X-GEM«, »MyDials« zu den »Spoil-Dials«, kein Name erscheint zu platt, als daß man ihn nicht seinen Dialogroutinen verleihen könne.
Sie alle haben die Eigenschaft, den Benutzerkomfort zu erhöhen und sind mehr oder weniger sowohl zu den Originalroutinen des TOS als auch untereinander inkompatibel. Und solange Atari keine eigenständige neue Normierung präsentieren kann, ist eine Vereinheitlichung in weiter Ferne.
Die Tücke liegt wie so oft, im Detail. Es beginnt bei der Frage, ob runde RadioButtons nur auf ihrem eigenen »Gebiet« oder auch auf dem rechts davon befindlichen Text zu selektieren sind, begleitet die Frage, ob und wie »hinter« die Dialoge zu schauen ist und endet beim Philosophenstreit über die Anordnung der »Abbruch«- und »OK«-Buttons. So legen sämtliche Atari-Applikationen und ein Großteil bestehender Software alle »Abbruch«-Knöpfe grundsätzlich nach rechts unten, andere Programme wiederum bestehen darauf, daß genau dort der »OK«-Button zu finden sei. Jede Seite führt entsprechende Argumente dafür an, daß das eigene Verfahren das einzig korrekte sei - eine wirklich intuitive Systembenutzung wird dem Atari dank der individuellen Programmgestaltung noch sehr lange vorenthalten bleiben.
Bleibt zu hoffen, daß entsprechende Style-Guides doch noch entworfen werden. Neben ein paar mündlichen Statements und einem StyleGuide-Anriß für das Design von »XCONTROL«-Modulen war bislang recht wenig erhältlich.
Um so ärgerlicher wird es, wenn hausgemachte Routinen nötig werden, um Fehler oder allzu harte Beschränkungen in den bestehenden TOS-Versionen zu umschiffen. Beispielsweise ist bislang kein Verfahren freigegeben, anhand dessen Resource-Files mit Längen über 32 KBytes zu laden wären. Bislang mußte ein mehr als wackliges Verfahren mehrere unabhängige Resource-Bäume laden. Der Resource-Editor »Interface« wird vermutlich der erste sein, der die magische 32-KByteGrenze durchbricht - schon auf der CeBIT 1992 war aus dem Hause »Shift« entsprechendes zu vernehmen. Natürlich wird auch »Interface« dazu eine eigene Routine verwenden, zumal ein neues TOS zwar durchaus in der Lage sein kann, diesem Manko abzuhelfen, aus Kompatibilitätsgründen wird jedoch ein eigenes runtime-»rsrc_load()« für die alten TOS-Versionen notwendig werden.
Ähnlich verhält es sich mit einem Bug, mit dem wir uns an dieser Stelle beschäftigen möchten. GEM sieht grundsätzlich das Verstecken von Resourcebäumen vor. Dies gestattet es, auf Wunsch Teile von Resourcen nach Belieben aus und wieder einzublenden. Daß dieses Verfahren mehr als ein didaktisch konstruiertes Beispiel ohne praktischen Wert ist, zeigt ein Blick auf Ataris Kontrollfeld XCONTROL. Hier stellt sich dem Programmierer die Aufgabe, viele Informationen auf geringem Platz nach Möglichkeit übersichtlich darzustellen. Das wird ohne das »Umschalten« zwischen mehreren Sub-Trees kaum möglich sein. Nun könnte man sich natürlich die Arbeit machen, Objektbäume nach Wunsch ein- und wieder auszuhängen. Erheblich einfacher ist es jedoch, die unerwünschten Resourceteile auszublenden, indem man die »HIDETREE«-Bits im »ob_flags«-Feld der Objektstruktur setzt. Die GEMFunktionen »objc_draw()«, »objc_find()« sowie »form_do()« sollten dies berücksichtigen.
Soviel zur Theorie. In der Praxis funktioniert das aber leider nicht. Es funktioniert deshalb nicht, weil die Betriebssystemprogrammierer offensichtlich vergessen haben, Objekte, die den Status »EDITABLE« besitzen, ebenfalls zu vernachlässigen.
So wird es möglich, mit dem Text-Cursor einer Dialogbox in den versteckten Unterdirectories herumzufahren und dort sogar noch Eingaben zu machen und damit Unheil anzurichten. Texteingaben werden akzeptiert und sogar ausgegeben - der Bildschirm-GAU ist vorprogrammiert.
Eine Beseitigung dieses Fehlers würde nun aber niemandem helfen. Zum einen würden bestehende Programme, die sich auf diesen Bug verlassen, fortan ihren Dienst verweigern, zum anderen müßten sich die Programmierer aus Kompatibilitätsgründen ohnehin workarounds ausdenken: schließlich hilft es Ihnen wenig, wenn Ihre neuen Programme nur noch mit den neusten TOS-Versionen laufen.
Zwar gilt mittlerweile bei den meisten Programmierern als ungeschriebenes Gesetz, daß die TOS-Versionen 1.0 und 1.02 aufgrund ihrer mannigfaltigen Fehler nicht mehr unbedingt berücksichtigt werden müssen. Auf die weitverbreitete TOS-Version 1.04 wird jedoch trotz der mittlerweile vorhandenen und erheblich verbesserten TOS-Version 2.06 noch auf einige Zeit hin Rücksicht genommen werden.
Schließlich sind über den Zeitraum von drei Jahren lang sämtliche Atari-Rechner mit diesem Betriebssystem bestückt worden, die Zahl der 1.04-Benutzer ist einfach noch zu groß, als daß man sie ignorieren könnte. So würde auch die einfache Beseitigung des "HIDETREE«-Bugs recht wenig Nutzen bringen. Deshalb schlagen wir an dieser Stelle ein flexibleres Korrekturverfahren vor.
Unsere Routinen »lock_editables()« und »release_editables()« entfernen die »EDITABLE«-Bits im »ob_flags«-Feld des Objektes und setzen als Markierung ein Bit im High-Byte des »ob_flags«-Words. Anhand derer können bei Bedarf die EditFelder wiederhergestellt werden. Unsere Beispielroutinen verwenden das oberste Bit des High-Bytes, selbstverständlich können Sie aber auch andere Bits hierzu wählen.
Falls Sie erweiterte Dialogroutinen verwenden, müssen Sie selbstverständlich im Auge behalten, daß dieses Bit nicht bereits durch andere Funktionen belegt ist. Als Parameter werden der Zeiger auf den zu durchsuchenden Objektbaum sowie der Index des Startobjekts übergeben, bei dem die Suche beginnen soll.
Zum Abschluß der Rekursion ist derjenige Wert anzugeben, den »obj« annehmen muß, um die Schleife zu beenden. Es empfiehlt sich hier, die Nummer des nächsten, gleichgeordneten Objektes anzugeben. Sie entspricht falls keine in der Hierarchie gleichgeordneten Objekte existierten, was beispielsweise bei einem Komplettdurchlauf einer Dialogbox der Fall wäre. Natürlich können so auch ganz bestimmte Objekte explizit erkundet werden, was jedoch nicht unbedingt sinnvoll erscheint. Ein Beispielaufruf wäre also:
lock_editables (tree, EDIT, tree[EDIT].ob_next);
Damit würde das Objekt »EDIT« im Baum »tree«, sowie alle ihm untergeordneten Objekte (Children) überprüft werden. Die Routine »transformers« beschreiben wir in der nächsten Programmiererecke. (uw)