vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Mails senden, abrufen und decodieren - ganz easy ;-)  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   RSS-Feeds  | Newsletter  | Impressum  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2014
 
zurück
Rubrik: Entwicklungsumgebung · Fehlerbehandlung   |   VB-Versionen: VB616.07.09
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 SiebertBewertung:     [ Jetzt bewerten ]Views:  6.174 
ohne HomepageSystem:  Win9x, WinNT, Win2k, WinXP, Vista, Win7, Win8 Beispielprojekt 

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.

Dieser Tipp wurde bereits 6.174 mal aufgerufen.

Voriger Tipp   |   Zufälliger Tipp   |   Nächster Tipp

Über diesen Tipp im Forum diskutieren
Haben Sie Fragen oder Anregungen zu diesem Tipp, können Sie gerne mit anderen darüber in unserem Forum diskutieren.

Neue Diskussion eröffnen

nach obenzurück


Anzeige

Kauftipp Unser Dauerbrenner!Diesen und auch alle anderen Tipps & Tricks finden Sie auch auf unserer aktuellen vb@rchiv  Vol.6
(einschl. Beispielprojekt!)

Ein absolutes Muss - Geballtes Wissen aus mehr als 8 Jahren vb@rchiv!
- nahezu alle Tipps & Tricks und Workshops mit Beispielprojekten
- Symbol-Galerie mit mehr als 3.200 Icons im modernen Look
Weitere Infos - 4 Entwickler-Vollversionen (u.a. sevFTP für .NET), Online-Update-Funktion u.v.m.
 
   

Druckansicht Druckansicht Copyright ©2000-2014 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.

Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel