Proper Debugging Without a Debugger

Every once in a while, you'll find yourself "flying blind" when trying to debug an application because the debugger won't work for your situation. Sometimes it's due to bugs in the debugger, and plenty of times it's because you're not setup properly to handle some situations (for example, if you only have one computer, it's impossible to remote debug errors with your Paint or Activate events).

So how do you debug your application?

You're certainly not dead in the water, that's for sure. Many people like to use MsgBox'es throughout their application to see what's going on and where things are at. This concept seems fairly sound, and it helps a lot when you're trying to see what the state of some variables are. However, it's also about the worst possible way to debug your application.

You see, MsgBox mucks with the state of the running application, which is something that skews your results drastically. When a MsgBox appears, it calls App.DoEvents internally because it's a modal dialog. Due to this, you can run into all sorts of interesting issues. For example, if you're inside of some events, the MsgBox may trigger other events to fire. At the very least, it causes Activate, Deactivate and Paint events to be called. So while it may work for you in some situations, it's by no means a good way to debug your application.

New to RB 5.5 is a handy function on the System module called DebugLog. This API was implemented to let you handle these situations and should always be used instead of a MsgBox for debugging purposes. What this API does is print a string out to a debugging mechanism that is appropriate for the platform you're running on. It won't change the state of your application because the message is printed out to a 3rd party logging mechanism.

So what are these logging mechanisms?

On Mac OS X, all messages are like DebugStr's -- they're printed out to the Console application. So to see the messages, first fire up Console (it's in your Applications:Utilities directory I believe) and then run your application.

On Mac Classic, the messages are still like DebugStrs, but they're printed out to MacsBug. This is a system extension that Apple provides for free (so you'll have to download it first) as a system level debugger. It's a must-have for anyone seriously considering developing for Classic. When the DebugLog is called, your application will break into MacsBug (so it halts your application's execution like a system debugger should) and display the string. You can press "g" and hit enter to continue your application running.

On Linux things are slightly more tricky. Linux has system logging mechanisms which you can get to with System.Log, but debug logging traditionally happens on the terminal. So you need to launch the application from a terminal window to be able to see the debug messages. Once you've launched your application from the terminal, all the DebugLog's will be printed out as if they were using printf (so they go to stdout).

Finally, for Windows applications, you'll need to download a separate application to read the debug messages. I would suggest getting DebugView from SysInternals; it's a free application and works very well. For this platform, the messages are written out using OutputDebugString (so any system debug string viewer will catch the messages, including kernel debuggers for Windows).

Again, since it's always a 3rd party application that's receiving the messages, your application's state is not going to be monkeyed with. Even in the case of MacsBug (and that's because MacsBugs actually halts the executable at the kernel level and restarts it when you hit 'g' like nothing ever happened). So always use System.DebugLog whenever you need to do some debugging and REALbasic's debugger cannot be of assistance. Resist the urge to use MsgBox -- it will only get you into trouble some day!