|
|
23.04.2024 | Archiv # Recherche # Links # Kontakt # Gästebuch # Impressum |
Index Login Die Anzeige des Archivs erfolgt grafisch. Ändern |
GeoBasic (Teil 1)Das Problemkind der Geos Familie: GeoBasic. In diesem 3teiligen Workshop sollen Probleme und Lösungen gezeigt und im Verlauf ein Programm entwickelt werden. Teil 1: Probleme und Lösungen "Neue Impulse zum Thema >>Basic<< gibt Berkely Softworks mit seinem GeoBasic. Mit GeoBasic wird man nicht nur Programme schreiben können, welche die Windows und Pull-Down Menüs von GEOS ausnutzen. Mit einem speziellen Editor lassen sich Flußdiagramme eingeben, die GeoBasic automatisch in die entsprechenden Programme übersetzt." (aus: 64'er. Heft 4/88) Schon diese Ankündigung - zwei Jahre (!) vor Erscheinen von GeoBasic - ließ die Erwartungen ansteigen. Dann kam GeoBasic und damit der große Reinfall. Das man mit diesem Programm dennoch halbwegs nützliches machen kann, will ich in diesem Workshop zeigen. Zu Beginn jedoch einige Tips & Tricks, etwas zu neuen Befehlen und zu den Fehlern von GeoBasic. Dabei setze ich voraus, daß Ihr den Workshop von Thomas Haberland aus dem 64'er SH 59 kennt und möglichst auch den Artikel in SH 80 gelesen habt, da der Platz hier nicht reicht, die dort erwähnten Sachen auch nur stark gekürzt wiederzugeben. Zunächst etwas zu "Sample Appl." auf der Geo Basic-Programmdiskette: Das dieses Beispielprogramm nicht editiert werden kann und es von J. M. Groß durch Neueingabe "repariert" werden konnte, dürfte jedem bekannt sein. Doch warum ist es defekt? Als Erklärung läßt sich vermuten, daß die Programmierer das UPDATE-Kommando aus dem FILE-Menü verwendet haben. Dieses ist defekt und erzeugt bei Verwendung genau den Fehler von "Sample Appl."; also das Programm ab und zu durch FILE/CLOSE und anschließendem OPEN aktualisieren und Update nicht benutzen, da beim weiteren Programmieren sonst unvermittelt ein "Bad BAM error" und eine Programmzerstörung auftreten können. Zum Thema defekte Diskettenbefehle gehört auch der BITMAP-Befehl. Wenn er nach einem Diskettenbefehl verwendet wird, funktioniert er nicht mehr. Das GeoBasic-Programm muß zuvor im Programm erst neu geöffnet werden (s. SH 59, Seite 12), damit die VLIR-Tabelle wieder stimmt. Was für UPDATE gilt, gilt auch für das Löschen mehrerer Zeilen mit DELETE: Auch dadurch kann ein Programm zerstört werden, am besten also die einzelnen Zeilennummern eingeben und jedesmal RETURN drücken. Mit PRINT CHR$(27) soll das Zeichen links vom Cursor zu löschen sein. Allerdings hat GeoBasic durch die Proportionalschrift starke Probleme, meist wird zuviel oder zu wenig gelöscht. Auch die Zufallsfunktion hat es in sich, probiert doch einfach mal folgendes Programm aus: 10 CLS 20 SETCOL 1 30 POINT RND(319),RND(199) 40 GOTO 30 Ist hier etwa von Zufall zu sprechen? Doch nun zu einer Funktion, die ich selber sehr interessant finde, das POP-Command. Es wird nirgendwo im Handbuch erwähnt. Diesmal hat es auch einen guten Grund: Wenn GeoBasic auf diesen Befehl stößt, gibt es den berühmt - berüchtigten "Systemfehler nahe...". Doch mit einem Patchprogramm von Wiliam Coleman kann eine GeoBasic V1.1 erzeugt werden, in dem dieser Befehl sauber funktioniert. (Das Tool gibt's in der PD-Bibliothek der Regio Hannover, Adresse siehe unten.) Ihr werdet euch vielleicht schon fragen: Was macht POP? Es entfernt die letzten beiden RETURN/UNTIL oder LOOP-Zeiger vom Stack, das Programm "vergißt" also, daß es in einer Unterroutine ist. Es darf nun nach POP kein RETURN/UNTIL oder LOOP, daß sich auf einen alten Aufruf bezieht, folgen. Anwendungszweck könnte z. B. sein: wenn in einem Unterprogramm ein Fehler auftritt, sollte nicht direkt in die Mainloop zurückgesprungen werden, sondern erst ein POP und dann ein Sprung in die Fehlerauswertungsroutine, die mit MAINLOOP abschließt, stattfinden. Achtung: Mit Fehler sind hier keine Fehler gemeint, die mittels ONERR kontrolliert werden können. Am besten experimentiert ihr etwas mit dem folgenden Beispielprogramm (NUR für GeoBasic 1.1 !!!): 10 CLS 20 PRINT "Hauptprogramm" 30 GOSUB @sub 40 PRINT "Wieder im Hauptprogramm" 50 END 100 @sub 110 PRINT "Unterroutine" 120 POP : rem oder return 130 PRINT "Nach der Unterroutine" 140 END Manchmal kann es passieren, daß mit FONT"BSW",9 die Systemschrift nicht aktiviert wird, dann hilft CALL 49483. DBSTRN CHR$(27)+"Text: ",TMP$ Statt CHR$(27) sind auch die anderen Steuercodes möglich, selbst Kombinationen sind zulässig. GeoBasic kann auch in NLQ drucken, und das unabhängig von der aktuellen Schrift. Bekanntlich schaltet PRNTER 1 die Ausgabe auf den Drucker um. Mit PRNTER 2 wird zusätzlich noch der NLQ-Druck aktiviert. Leider geht dies nicht mit jedem Drucker(treiber). In der Anleitung ist leider nicht erwähnt, daß der ICON-Befehl zuerst den Screen mit Muster 2 füllt; ärgerlich, wenn man schon eine Maske erstellt hat und dann Icons aktivieren will. Wenn man den Variablenspeicher mittels RESIZE auf 8 kByte stellt, hat man 7098 Byte (laut PRINT FRE(0)) zur Verfügung. Da 8 kByte aber 8192 Byte sind, unterschlägt GeoBasic 1094 Byte, also mehr als 1 kB! Wer ein fehlerfreies Programm erstellt hat und daraus eine eigenständig lauffähige Applikation macht, wird sicher schon mal festgestellt haben, daß diese ab und zu zum DeskTop zurückkehrt, ohne daß es vorgesehen ist. In diesem Fall hilft es, den Variablenspeicher so groß wie möglich zu machen, dann dürfte es keine Probleme geben. Offensichtlich benutzt die GeoBasic-Run-Time-Bibliothek Variablenspeicher, die der Interpreter nicht braucht! Entgegen dem (von der 64'er Redaktion hinzugefügten) Hinweis im Workshop aus SH 59 wird es zu GeoBasic definitiv kein Update geben, der Vertrieb ist vielmehr seit einiger Zeit eingestellt; eventuell sind noch einige wenige Restexemplare zu finden. Für Rückfragen zu GeoBasic hier nun meine Adresse: Bitte frankierten Rückumschlag beilegen, bei Disksendungen (nur 1541) auf angemessene Verpackung zur Rücksendung achten. Rückfragen zum Patch von GeoBasic beantworte ich gerne, für weitere Kontakte zur Regio Hannover bitte an Thomas Schreiber schreiben; siehe Regio Berichte in der GUP. Im nächsten Teil werde ich zeigen, wie man trotz der vielen Fehler gut mit GeoBasic programmieren kann.
Olaf Dzwiza
Kurzlink hierhin: http://geos-printarchiv.de/1538 |
Letzte Änderung am 01.11.2019 |