Rubrik: Entwicklungsumgebung · Fehlerbehandlung | VB-Versionen: VB6 | 16.07.09 |
![]() Fehler treten natürlich immer beim Kunden auf. In fast allen Fällen besteht keine Möglichkeit dort zu Debuggen. Mit Hilfe des gezeigten Tipps besteht die Möglichkeit Debug-Ausgaben zu aktivieren, diese an einen Viewer zu senden und/oder in eine Datei auszugeben. | ||
Autor: ![]() | Bewertung: ![]() ![]() ![]() ![]() ![]() | Views: 13.371 |
ohne Homepage | System: Win9x, WinNT, Win2k, WinXP, Win7, Win8, Win10, Win11 | ![]() |
Bisher bin ich bei meinen Programmen mit Debug-Ausgaben so verfahren, dass ich Compiler-Flags gesetzt habe.
Beispiel:
#If Debug_TraceIn Or Debug_ Then glLog.TraceIn MyName & ".Main" #End If
Das hat natürlich zur Folge, dass im Falle eines Fehlers eine neue EXE-Datei erstellt werden muss, welche diese Compiler-Flags aktiviert hat. Oftmals natürlich nicht gerne gesehen. Die Idee, die ich daraufhin hatte war, eine Schnittstelle zu erstellen, welche durch zwei Klassen implementiert wird. Hierbei erzeugt eine der Klassen alle nötigen Debug-Ausgaben und die zweite Klasse stellt eine Dummy-Klasse dar.
Ausschnitt Schnittstelle:
Public Function TraceError( _ ByVal sFunction As String, _ ByVal msg As String, _ Optional ByVal vPrintErr As Boolean = False _ ) As Boolean End Function
Ausschnitt Dummy-Klasse:
Public Function IDebug_TraceError( _ ByVal sFunction As String, _ ByVal msg As String, _ Optional ByVal vPrintErr As Boolean = False _ ) As Boolean IDebug_TraceError = True End Function
Ausschnitt Debug-Klasse:
Public Function IDebug_TraceError( _ ByVal sFunction As String, _ ByVal msg As String, _ Optional ByVal vPrintErr As Boolean = False _ ) As Boolean Dim tmpStr As String tmpStr = sFunction & ": " & msg If vPrintErr Then tmpStr = tmpStr & " - " & CStr(Err.Number) & ": " & Err.Description End If DebugOutput tmpStr IDebug_TraceError = m_StopOnError Debug.Assert IDebug_TraceError End Function
Die private Function DebugOutput verteilt dann die Ausgaben:
Private Sub DebugOutput( _ ByVal Data As String _ ) Debug.Print Data ' Watch Window Ausgabe OutputDebugString Data ' DbgView Ausgabe, Erklärung folgt If m_boWriteFile Then PrintMsg Data ' Datei Ausgabe, siehe Beispielprojekt End If End Sub
Die Function OutputDebugString sendet Debug-Ausgaben an den Windows-Kernel - API Deklaration:
Private Declare Sub OutputDebugString Lib "kernel32" _ Alias "OutputDebugStringA" ( _ ByVal lpOutputString As String)
Das frei verfügbare Programm DbgView fängt diese Ausgaben ab und zeigt sie an. Dieses Programm bietet z.B. auch die Möglichkeit mit einem zweiten seiner Art Remote zu kommunizieren! Lest dazu aber bitte die Hilfe und Beschreibung von DbgView.exe. Sollten Debug-Ausgaben gesendet werden und DbgView.exe ist nicht aktiv, passiert nichts. Die Ausgaben verhallen ungehört im System.
Mittels zweier Routinen, welche in ein Standardmodul gepackt werden können, kann dann die Debug-Ausgabe de-/aktiviert werden:
Public Sub DebugEnable() Set DBGView = New CDebug DBGView.Init "MyProject", False, True 'Siehe Download End Sub
Public Sub DebugDisable() Set DBGView = New CDebugNull DBGView.Init "MyProject", False, False 'Siehe Download End Sub
Falls erforderlich, kann geprüft werden, welche Ausgabe aktiv ist:
Public Property Get DebugEnabled() As Boolean DebugEnabled = (TypeOf DBGView Is CDebug) End Property
Die Ausgabe in das Dummy-Objekt oder in das richtige Debug-Objekt, kann problemlos zur Laufzeit umgeschaltet werden. Ich habe das z.B. so realisiert, dass die Debug-Ausgabe aktiviert wird, wenn im Hauptform zweimal <Strg><w> innerhalb von 2s gedrückt wird.
Nun wäre noch zu klären, warum die Debug/Trace Funktionen der Schnittstelle als Functions und nicht als Subs ausgelegt wurden. Der Vorteil liegt darin, dass im Code geschrieben werden kann:
Debug.Assert DBGView.Trace(MyName & ".AFunction", "AString")
Und ich damit die Möglichkeit habe, direkt bei der Entwicklung zu entscheiden, dass diese Ausgabe niemals in der Exe enthalten sein soll. Das geht so mit einer Sub nicht.
Außerdem habe ich die Möglichkeit durch Suchen und Ersetzen den/die Text(e) Debug.Assert DBGView. durch Call DBGView. und umgekehrt zu ersetzen, falls Bedarf besteht ein Release ohne/mit Debug-Ausgaben zu erstellen.
Zusammenfassung:
Der Tipp (insbesondere der Download) zeigt, dass einiges möglich ist um den Entwickler auch vor Ort zu unterstützen. Besonders interessant finde ich persönlich die Ausgabe an DbgView, womit sozusagen eine Online Kontrollmöglichkeit besteht. Es ist natürlich klar, dass diese Lösung nicht ohne Kosten hinsichtlich Performance und Speicher integriert werden kann. So lange die (Dummy-)Debug-Aufrufe aber nicht in einem Bereich liegen welcher sehr rechenintensiv ist, bzw. häufig durchlaufen wird, ist dies zu vernachlässigen.
Außerdem, hoffe ich mit dem Tipp, eine schöne und sinnvolle Anwendungsmöglichkeit von Schnittstellen und Klassen aufgezeigt zu haben.