So, You Want To Write Windows Apps (X) A step-by-step guide |
By Barbara Brazil |
|
Previous Chapter | Table of Contents |
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:
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 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 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 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 .IFDEF DEBUG This method also works really well for debugging over Comet Anywhere. Popup Dialogs 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 |