#Const afLogfile = 1
#Const afMsgBox = 2
#Const afDebugWin = 4
#Const afAppLog = 8
The problem with using the new logging system for debug messages is that it’s designed for a different purpose—logging events in unattended applications. If you’re using the built-in logging system for its intended purpose, you might want to use a different BugMessage setting so that debug messages don’t get mixed in with other logged events. If you do decide to use the App object log features, you can control whether events are written to a log file or, under Windows NT, to the Application Event Log. The official logging system unfortunately doesn’t work at all in the IDE (a fatal flaw in my opinion). My logging system doesn’t attempt to call the StartLogging method or set the LogMode or the LogPath properties. It simply writes messages with the LogEvent method. If you use this option, you’ll need to initialize the logging system yourself.
FLAME The new Debug.Assert method only works in the IDE, not in executables. The new log methods and properties of the App object work only in executables, not in the IDE. It’s a conspiracy. Sometimes a flawed feature is better than no feature, but in this case neither feature is good enough to be used for real debugging scenarios.
Sub BugMessage(sMsg As String)
#If afDebug And afLogfile Then
If iLogFile = 0 Then
iLogFile = FreeFile
‘ Warning: multiple instances can overwrite log file
Open App.EXEName & “.DBG” For Output Shared As iLogFile
‘ Challenge: Rewrite to give each instance its own log file
End If
Print #iLogFile, sMsg
#End If
#If afDebug And afMsgBox Then
MsgBox sMsg
#End If
#If afDebug And afDebugWin Then
Debug.Print sMsg
#End If
#If afDebug And afAppLog Then
App.LogEvent sMsg
#End If
End Sub
If you open a log file for debug information, who’s going to close it? Well, DEBUG.BAS contains a BugTerm sub that you can call in the Unload event of your main form to close the file. If you don’t bother, however, you’ll probably still be OK because Visual Basic closes all open files when it terminates. No-tice that log files have the project executable name and the extension DBG. You might want to clean up once in a while so that your disk doesn’t fill up with obsolete DBG files.
CHALLENGE The traditional Windows output destination is a debugging terminal. You hook up a dumb terminal to your serial port and send debugging output to the port. Assertions and other debug messages scroll past on this Neanderthal device without interfering with the operation of your program. The Windows API provides the OutputDebugString function to send output to a debugging terminal, but I was never able to get this to work satisfactorily under 32-bit Windows. You could enhance the BugMessage sub by adding an option that opens a COM port and then writes output to it.