So, You Want To Write Windows Apps (X)
• • • A step-by-step guide
By Barbara Brazil• • •



Debugging Your Windows App


    |    


You may not be able to use your normal debugging techniques with your new app, but once you see what other ways of debugging are available to you, you won't believe you were ever able to get along without them. The way I had debugged my IB programs for years was by printing out messages to myself on the screen followed by a WAIT statement. I'm sure you've all used that technique. Well, depending on what style of Windows app you've written, you can't necessarily do it that way anymore.

Your Windows program will be one of three styles:

  • Embedded dialog
  • Popup dialog
  • FreeForm Window

Each style has particular debugging methods which are suitable for it, but there are a couple which apply to all of them as well as every other IB program. The first, and definitely the simplest to use, is the IB LOG statement. It will send your debug messages to the CosC log file. You can view this by clicking on "View" then "Startup Details" from the menu at the top of the Comet window.

The Comet Debugger
Another method which applies to all IB programs for which you have the source is the Comet Debugger. Introduced in Comet 2003, this is by far the most powerful way to debug. I can step through each line of code to see exactly how my logic flows and how contents of my variables change at each step. If I suspect my problem is in a particular section of code I can tell the debugger to run up to that point and then stop so I can have a look around and find my problem. I can even alter the contents of the variables to simulate what would happen if they were different and then continue execution. It is absolutely amazing! Definitely the fastest way to track down your problem.

There's lots more you can do with the debugger. I'm not going to go into that now. You can get the whole scoop about it here: http://www.signature.net/signature/techdoc/debugger/debugger.htm. The only restrictions are that you must have the source and that source must be in text file format. No CED files allowed. It really is terrific. The only time I'm not able to use it is if I'm trying to debug over Comet Anywhere. Since the debugger is a .exe, you need access to the system's console to use it.

Embedded Dialogs
The Data Express programs are embedded dialogs. This means that the dialog is embedded in the Comet window. It completely covers it. You cannot move it away. PRINT and INPUT statements are QCRT functions. They only work on the Comet window. There's the problem.

Second to the debugger, I find that creating a separate window just for my debugging messages works best. I got this one from Brian and I think it's really clever. You use the CreateWindowEx mnemonic to create a little window into which you can PRINT whatever you like. You can move the window around so it's out of your way. You can even INPUT from it as long as you click on it to give it the focus. What we do is setup a symbolic constant at the top of our programs that we set to TRUE or FALSE to turn on or off the code for the window. I don't know about you, but after I make the initial release of a product someone invariably finds a bug that I have to go back in and fix so being able to get my debugging window back easily is important. Here's how to do it:

Add these lines to the declarative section of your program:

SET DEBUG = TRUE                    ! TRUE enables debug window.
.IFDEF DEBUG
   Length 4 & Local DebugWin$    ! This is to save the window's handle
.ENDIF

Add these lines to the beginning of your executable code:

.IFDEF DEBUG
   Print (CreateWindowEx=0,0,60,25,580,0,"My Debug Window")
   Input DebugWin$
   Print (Et);"My Debug Messages..."
.ENDIF

This creates a window that's 60x25. The style parameter (580) indicates we want the window to be visible (64), that we want a caption bar (4), and that we want it to show in our system tray (512).

Lastly, you need to be sure to delete the window before you exit your program so include these lines as the last thing you do:

.IFDEF DEBUG
   If (DebugWin$ NE "")
      cosCWnd$ = DebugWin$
      Gosub COS.SetFocus
      Print (DeleteWindowEx = DebugWin$)
   EndIf
.ENDIF

Then when you want to print a message into your window you just use the PRINT statement:

.IFDEF DEBUG
   PRINT "this is my debug message"
.ENDIF

Since you set typewriter mode, the messages will scroll up with each write. To turn the window off all you need to do is change the value of the SET statement at the top to FALSE.

This method also works really well for debugging over Comet Anywhere.

Popup Dialogs
Popup dialogs are not embedded in the Comet window. DlgDemo is an example of a popup dialog. They can be either modal or modeless. DlgDemo is modal. This means that you cannot take the focus away from it by clicking on another window. You're stuck in the dialog until you're done.

A popup dialog is separate from the Comet window and you can move it around wherever you want. This means that you can actually see the Comet window. Because of that you can PRINT to it. If it's modeless, you can use the Comet window for your debug messages and even INPUT from it by simply clicking on it to give it the focus. If it's modal, however, you can still PRINT to the Comet Window but there is no way to INPUT from it since you can't click on it to give it the focus. Don't even try. You'll hang up your program!

FreeForm Windows
FreeForm Windows are the programs like Jim's DirCat and my CtlDemo. They are not dialogs. Each control was created programatically in IB code. Because you're doing all your work directly in the Comet window, you can use the same old debugging methods you've used for years. I really suggest you give one of these methods a try though, especially the debugger. You'll find those bugs faster and have more time to improve the appearance of your apps.

    |