Einfaches debuggen von dBASE-Programmen

Zur Entwicklungsumgebung von dBASE Plus gehört auch ein moderner Debugger. Mit ihm können Sie den Programmablauf an beliebigen Stellen unterbrechen (sog. Breakpoints), können Inhalte aller Variablen während der Laufzeit einsehen und beobachten, welche Codeabschnitte wann durchlaufen werden. Das ist nicht nur zur Fehlersuche sehr nützlich, sondern Sie lernen so auch ganz nebenbei wie dBASE “tickt”. Dumm nur, wenn so ein Debugger selbst den einen oder anderen Bug hat …

Das fängt schon damit an, dass der dBASE Debugger garnicht benutzbar ist, wenn Sie ihn direkt aufrufen. Sie können zwar das Programm plusdebug.exe separat starten, das sich im Unterverzeichnis bin Ihrer dBASE-Installation befindet. Sie können auch noch eine prg– oder wfm-Datei in den Debugger laden. Doch das war´s, mehr geht nicht, weil alle Menüpunkte und Symbole um das zu testende Programm zu starten disabled sind.

Die Lösung ist ganz einfach: statt den Debugger direkt zu starten, rufen Sie ihn indirekt über das dBASE Befehlsfenster auf:

debug xyz.prg

So startet der Debugger, lädt die gewünschte Programmdatei, Sie sehen deren Quellcode, können Haltepunkte setzen oder löschen und selbstverständlich auch das Programm starten.

In dem Zusammenhang noch ein paar Tips (Deutschlehrer denken sich bitte das zweite p).

Für simple Testausgaben, z. B. Infotexte oder Variablen-Inhalte etc., können Sie einfach eine Windows Messagebox in den Programmcode einbauen, z. B. so:

msgbox ( “sVar enthält: ” + sVar, “Debug”, 0 )

Die kann bei Bedarf auch mehrzeilige Texte enthalten und mit Tabulatoren formatiert sein:

msgbox ( “Var1: ” + chr(9) + sVar1 + chr(13) + “Var2: ” + chr(9) + sVar2 , “Debug”, 0 )

Das chr(9) erzeugt einen Tabulator (dessen Grösse allerdings nicht beeinflussbar ist), mit chr(13) fügen Sie einen Zeilenvorschub ein.

Wenn Sie nicht wollen, dass eine Meldung den Programmablauf unterbricht, geben Sie den Text doch einfach in der Titelzeile oder in der Statuszeile des Programmfensters aus:

_app.framewin.text = “sVar enthält: ” + sVar
set message to “sVar enthält: ” + sVar

Die Statuszeile sollte dann natürlich eingeschaltet sein. Meist ist sie das, und falls nicht:

_app.statusbar = .t.

Für simple Checks, ob ein Programmteil überhaupt durchlaufen wird, z. B. nach einer IF-Entscheidung, genügt oft ein Piepser. Ertönt er, wurde der Programmteil durchlaufen.

set console on
? chr ( 7 )

Das chr(7) erzeugt den sog. System-Beep, ein ganz einfacher Ton, den Sie bestimmt schon tausendfach gehört haben. Das vorherige set console on stellt dabei sicher, dass der Ton auch ausgegeben wird, denn bei der Einstellung set console off würden Sie nichts hören.

Eine Gefahr bei diesen zusätzlichen Debug- und Testcodes will ich Ihnen nicht verschweigen: Es passiert schon mal, dass man nach dem Test vergisst, die zusätzlichen Ausgaben oder Piepser wieder zu entfernen. Dann wird das Programm inkl. Testmeldungen und Piepser ausgeliefert, und der Kunde wundert sich … Ehrlich gesagt war das über viele Jahre hinweg mein “Lieblingsfehler”. Dagegen hilft die Verwendung eines #defines, welches sämtliche Testcodes umschliesst, so dass die Tests nur ausgeführt werden, wenn das #define auch definiert ist. Jetzt dürfen Sie nur daran denken, das #define am Ende auch aufzuheben …

#define DEBUGGER

#ifdef DEBUGGER
_app.framewin.text = “Ich bin nur ein Test”
#endif

Im obigen Beispiel ist das #define DEBUGGER aktiv, die Zeile mit _app.framewin… wird ausgeführt. Sie müssen natürlich alle Debug-Befehle konsequent mit #ifdef DEBUGGER und #endif umschliessen. Sind Ihre Tests abgeschlossen und das Programm ist fehlerfrei (…), ändern Sie nur das #define, z. B. indem Sie ein * davor setzen um es zu deaktivieren:

*#define DEBUGGER

Jetzt ist DEBUGGER nicht mehr definiert, und damit werden auch alle Befehle, die zwischen #ifdef DEBUGGER und #endif stehen, nicht mehr ausgeführt. Trotzdem können alle Test-Anweisungen im Code bleiben, denn wer weiss wie Sie sie später doch noch mal brauchen.

Gross- und Kleinschreibung der #define Begriffe ist übrigens beliebig. Es ist nur in der Programmiererzunft stark verbreitet, sie stets gross zu schreiben, so wie oben gezeigt.

(Stand dieser Info: 2012)