In compiliertem GFA-BASIC wird beim Laden des Programm-Codes grundsätzlich der Bildschirm gelöscht. Dafür sorgt ein ‘Initialisierungs-String’, der in dem Compilat ab dem 30. Byte enthalten ist. Nun ist es aber besonders bei Programmen, die mit einer GEM-Umgebung arbeiten nicht wünschenswert, daß der Bildschirm gelöscht wird, da es stümperhaft aussieht, wenn der Hintergrund erst gelöscht und dann wieder aufgebaut wird. Mein kleines Programm ändert deshalb ein compiliertes Programm so ab, daß der Bildschirm nach dem Laden erhalten bleibt.
In einer Fileselektorbox wird der Name eines (compilierten GFA-BASIC-) Programmes eingegeben. Dieses Programm wird dann ‘geöffnet’ und der Dateipointer mittels des SEEK-Befehles auf das 30. Byte gesetzt. An dieser Stelle beginnt nun normalerweise der String, der den Bildschirm mit Hilfe einer Escape-Sequenz (wie ‘Print Chr$(27); Chr$(69)’ oder auch ‘Cls’) löscht (siehe Tabelle). Als Kennung für das Ende dieses Strings gilt das ASCII-Zeichen mit der Nummer 0. Also müssen wir nur das erste Byte dieses Strings ‘Auf Null setzen’, damit auf dem Schirm nichts passiert.
Das erledigt für uns der Befehl OUT #1.0. Dieser Befehl schreibt das Byte Null an die Stelle, auf die der Dateipointer zeigt. Da wir den Dateipointer bereits auf das 30. Byte gesetzt haben, wird es folglich mit Null überschrieben.
Wenn Sie das ‘behandelte’ Programm dann das nächste Mal laden, werden Sie feststellen, daß Ihnen der Bildschirm erhalten bleibt. Die Menüzeile, in der während des Ladevorganges der Name des Programmes steht, ist dann leer. Darunter bleibt der Schirm im grauen Farbton des GEM-Desktops.
Dieses Verändern des Compilats wird in einer READ_ME-Datei auf der GFA-BASIC-Compiler-Diskette vorgeschlagen. Somit brauchen Sie keine Angst zu haben, daß ein solches Vorgehen zu Datenverlusten o.ä. führen könnte.
Obwohl sich der Zeitaufwand für das Behandeln eines Programmes in engem Rahmen hält, wäre es doch sehr wünschenswert, direkt in den Compiler-Optionen einstellen zu können, ob der Bildschirm gelöscht oder ‘normal’ übergeben wird. Auch dies wäre eine kleine, aber doch sehr nützliche Option.
Einen weiteren Nebeneffekt dieses ‘Patches’ bemerkte ich bei einigen Programmen, die in meinen Auto-Ordnern ihren Dienst versehen. Wenn diese Programme nämlich eine Eingabe (Datum o.ä.) verlangen, so kann man die Daten schon vor dem Start des Programmes (immer hübsch langsam) eingeben. Normalerweise übernimmt das Programm das Eingetippte dann richtig; man sollte die Return-Taste jedoch erst dann betätigen, wenn man die Eingaben kontrolliert hat, denn beim Tippen ohne Bildschirm-Echo kann doch leicht etwas schief gehen...
So erspart man sich unter Umständen etwas Wartezeit. Womit dieser Effekt wohl zusammenhängt? Nun, daß vermag auch ich nicht zu sagen, allerdings schätze ich, daß das Löschen des Bildschirmes auch gleichzeitig den Tastaturpuffer leert. Wie gesagt, reine Spekulation...
Martin Fangmeyer
Byte | Inhalt | Funktion |
---|---|---|
30 | 27 | Escape (ASCII-Zeichen 27) kennzeichnet einen Grafik-Befehl (Escape-Sequenz) |
31 | 69 | Bildschirm löschen, Cursor in Home-Position |
32 | 27 | Escape-Sequenz |
33 | 102 | Sollte der Text-Cursor auf dem Bildschirm zu sehen sein, so wird er ausgeschaltet |
33 | 27 | Escape-Sequenz |
35 | 118 | Automatischer ‘Überlauf’ am rechten Rand aus |
36 | 0 | Ende des auszugebenden Strings |
Tabelle : Aufbau des Initialisierungsstrings (ab 30. Byte)
Text 60,13,"Bildschirm beim Laden von compiliertem
GFA-BASIC nicht löschen..."
Do ! Endlosschleife
Fileselect "\* .PRG", "", A$ ! Datei auswählen
Exit If Not Exist(A$) ! Schleife verlassen
Open "U",#1,A$ ! Datei zum korrigieren öffnen
Seek #1,30 ! Pointer auf 30. Byte setzen
Out #1,0 ! Byte löschen
Close ! Datei schließen
Loop ! Zurück zum Anfang
End ! Programm beenden
“NO CLS”-Patch für GFA-BASIC