Other Debug Messages


Assertions aren’t the only kind of debug message you might want to see. In a previous life, I worked on a FORTRAN run-time library containing an extremely complex system of debug outputs. By setting various command line options during a library build, you could dump different parts of the library entrails for easy run-time divination. Nothing (except good sense) prevents you from enhancing my debug code to something just as complex.


That’s up to you. I’m simply going to show you BugMessage. You can call it directly to display messages about your status and location, or you can write procedures that call it the way BugAssert does. My debug module (DEBUG.BAS) also contains a BugProfileStop sub that calls BugMessage to write profile information to the output destination.


BugMessage uses the following compile-time constants:

#Const afLogfile = 1
#Const afMsgBox = 2
#Const afDebugWin = 4
#Const afAppLog = 8

These identify the output destination for the message. Because your program is running under Windows, you have no command line to write to. You must send the message somewhere that won’t interfere with your program screen.


You can write to a dialog box, although dialog debug messages can get annoying. If you’re running in the Visual Basic IDE, you can write to the Immediate window. You also can write debugging output to a log file for later inspection. Finally, you can write messages to Visual Basic’s log system, which is controlled by properties and methods of the App object.

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 exe­cutables. 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.


A log file often works best in addition to (not instead of) one of the other output destinations. In theory you could set all four BugMessage bits at once, but in reality you’ll usually pick one of the first three and then consider adding the log file as a secondary destination.


Here’s the code to handle different output destinations:

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 inter­fering 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 sat­isfactorily 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.