Eigentlich war ein vierter Teil gar nicht geplant. Doch aufgrund einiger Anfragen und aktueller Publikationen (64'er Sonderheft 92) folgt nun dieser -endgültig- letzte Teil.
Bevor ich mich dem eigentlichen Thema zuwende, will ich einer häufig geäußerten Bitte nachkommen und die Lösungen der Aufgaben des zweiten Teils vorstellen.

Zum ersten Problem:
Hier ging es darum, eine Auswahlmöglichkeit zwischen A5 und A7-Druck zu schaffen (in der Aufgabe war leider ein Druckfehler, A4 ist unter GeoBasic völlig unmöglich!).
Am sinnvollsten ist es, die Druckroutine ab dem Label @Druck dahingehend zu verändern, unmittelbar vor dem Druck eine Abfrage zu machen, welcher Modus gewünscht ist.
Zunächst werden zwei Icons mit dem Text und Namen "klein" und "groß" erstellt. Bei "klein" soll der Wert 21, bei "groß" der Wert 20 zurückgegeben werden. Im Dialogboxeditor erstellen wir eine Dialogbox mit dem Text "Welcher Druckmodus?" und drei Icons: zwei Userdefinierte Piktogramme, die Bitmapnamen lauten gemäß Vereinbarung "groß" und "klein", sowie ein "Abbruch"-Icon.

Wenn die Box fertig ist, geht es zum Programm zurück und das Druckmodul wird gelistet:

   LIST @Druck,

Die Zeile 550 ist nicht mehr zu gebrauchen, sie wird nun ersetzt durch:

   550 DIALOG
   "Druck",auswahl

An dieser Stelle aus gegebenem Anlaß noch einmal die ausdrückliche Warnung vor der Verwendung des Befehls "Delete". Beim Löschen von mehreren Zeilen gleichzeitig wird das Programm unrettbar auf Diskette (!) zerstört.

Es folgt die Auswertung der Variablen "auswahl":

   551 IF auswahl=20 THEN
         PRSCREEN 1
   552 IF auswahl=21 THEN
         PRSCREEN 0

Für den Fall, daß "groß" angeklickt wurde, wird die große Druckroutine verwendet, bei "klein" entsprechend die normale. Wenn Abbruch angeklickt wurde, erfolgt kein Ausdruck ("auswahl" erhält intern den Wert 2, aber da alle Druckfälle bereits abgedeckt sind, muß dies nicht extra abgefragt werden).

Zum zweiten Problem:
Das Gitternetz sollte um zwanzig Pixel hochgeschoben werden. Wer den dritten Teil gelesen hat, weiß warum ich schrieb "braucht Ihr eine unveränderte Version". Jetzt solltet Ihr möglichst eine Version vom Stand "Ende Teil 2" einsetzten.
Das Problem ist leicht gelöst; Sämtliche y-Koordinaten in den Programmteilen @Hintergrund und @ZeichnePlan sind um zwanzig zu verringern.
In den Routinen @Druck und @NeuZeichnen gilt dies ebenso, nur dürfen die Werte 0 und 199, wenn sie an der y-Koordinatenstelle stehen, nicht veränden werden.

Doch nun zum eigentlichen Schwerpunkt dieses Teils:
Wer das 64'er SH 92 hat, sollte sich nun GeoBasic von seiner Arbeitsdiskette zusammen mit den drei "Hauptapplikationen" Weltzeit, Horoskop und GeoMensch auf eine separate Diskette oder in die RAM-Erweiterung kopieren. Wer das Sonderheft nicht hat, hat auch nichts versäumt.

Startet nun GeoBasic und staunet ...
Eigentlich wäre es zu erwarten gewesen, daß in der GeoBasic-Fileauswahlbox (siehe Bild) ...

... nur GeoBasic-Listings zu finden sind. GeoBasic zeigt jedoch auch fertige Applikationen mit RunTime-Bibliothek (im folgenden RTB) an! Öffnen wir einfach mal die Datei "Horoskop" und geben LIST ein. Und ... Es geht!

GeoBasic scheint nicht in der Lage zu sein, seine eigene RTB zu erkennen. Prinzipiell wäre es möglich, daß Programm nun zu editieren, die Editioren aufzurufen oder es mit RUN oder DEBUG zu starten. Abgesehen von den letzten beiden Befehlen sei davor jedoch gewarnt: Ich habe schon die unglaublichsten Abstürze erlebt...

Im übrigen sollte man sich den in den drei Programmen gezeigten Programmierstil nicht angewöhnen. Es ist durchaus möglich, mit GeoBasic strukturiert zu programmieren, siehe Teil 2 und 3.
Bevor wir das Programm "Horoskop" verlassen, sei zu dieser "Anwendung" noch gesagt, daß hier die Horoskope - wie in der Realität - per Zufallsgenerator festgelegt werden.

Anhand des Programms "GeoMensch" läßt sich eine weitere Eigenschaft der GeoBasic-RTB aufzeigen:

In GUP 29, Seite 7, wurde kritisiert, daß das Programm unsauber programmiert sei (leere Menüs usw.). Diese Kritik ist zurückzuweisen. Die Ursache liegt nicht beim Programmierer, sie liegt an GeoBasic und den Testern des Programms:

Beim Anhängen der RTB können sich Fehler einschleichen, z. B. solche, daß die Menüstruktur nicht richtig übernommen wird oder das die Applikation nach einen Start zum DeskTop zurückkehrt oder sogar abstürzt.

In einem solchen Fall ist die Applikation zu löschen und der Vorgang des Linkens zu wiederholen. Meist hat man nach dem zweiten oder dritten Durchlauf Erfolg. Dies alleine ist die Ursache für die leeren Menüfelder (möglichst nicht anklicken!), eine Tatsache, die den Testern und "Fachredakteuren" von M&T nicht bekannt zu sein scheint. (Im übrigen wäre es leichter gewesen, zum Blättern in diesem Programm Icons anstatt Menüs einzusetzen. Da letztere immer mindestens einen Eintrag brauchen.)

Sollte es immer noch zu Abstürzen kommen, ist der Variablenspeicher zu ändern (siehe Teil 1 in GUP 27). Wenn das Programm immer noch abstürzt, dann erst kann man sagen, daß der Fehler wahrscheinlich beim Programmierer liegt.

Betrachten wir noch das Programm "Weltzeituhr" aus dem Sonderheft, finden wir eine Meisterleistung der Tester von M&T. Das Programm verabschiedet sich sofort nach dem Öffnen mit einem Systemfehler!!!
Gehen wie genauso vor, wie beim Programm "Horoskop": In der Filebox öffnen und anschließend mit DEBUG starten! Es läuft!
Wird das Programm jedoch durch das Menü verlassen, erscheint die Fehlermeldung:    ?Undefinied Statement Error in 13

Zeile 13 enthält den Befehl MAINLOOP, also ist der Fehler im Menü. Nachdem wir das Menü durch den Menüeditor aufgerufen haben, schauen wir uns mal die "Verlassen"-Sprungadresse an: Zeile 2040. Doch diese Zeile fehlt im Programm!
Der Autor hat ein simples END vergessen. Leider dürfen wir dies nicht einfach anhängen. Mit Hilfe des PD-Programms "GeoStripper" läßt sich die RTB wieder von einem Programm entfernen. Nachdem wir dies getan haben, wird das Programm durch die Filebox geöffnet (wichtig, nur so geht es), folgende Zeile ergänzt:

   2040 END

und nach dem Sichern (CLOSE und wieder OPEN, niemals UPDATE) erneut gelinkt.

In allen drei Applikationen sollte man es tunlichst vermeiden, Hilfsprogramme aufzurufen: Der Autor hat vergessen, eine Routine zum Wiederaufbau es Bildschirms einzubauen.

Abschließend will ich noch darauf hinweisen, daß ich nicht befugt bin, die reparierte Version der "Weltzeituhr" zu kopieren (Copyright M&T). Verzichtet also bitte auf entsprechende Anfragen, ich würde sie nicht beantworten. Daß Programm "GeoStripper" hingegen gibt es gegen Unkostenerstattung bei mir. (DM 5 für Disk und Rückporto oder Disk, Porto und Verpackung beifügen).
Meine Adresse findet ihr am Ende des dritten Teils (GUP 28).

Olaf Dzwiza