De-/Aktivierbare Debug-Ausgaben auch für Applikation im Feld 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:   Dirk Siebert	Bewertung:     [ Jetzt bewerten ]	Views:  12.855
ohne Homepage	System:  Win9x, WinNT, Win2k, WinXP, Vista, Win7, Win8, Win10	Beispielprojekt

Geben Sie hier Ihre persönliche Bewertung ab! Anzahl Bewertungen bisher: 3 Bewertung insgesamt: sehr gut Durchschnittliche Bewertung: 5.0 von 5 Sternen

sehr gut     gut     nützlich     mittelmäßig     mangelhaft

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.