January 4, 2006

Debugger Tricks

As a user (of course) of SP Debugger for SQR, I occasionally find myself using it in new ways.

Recently I was faced with finding a problem in a large production SQR. Logic was split between the SQR and various SQCs. I didn't want to step through the code in the debugger yet, but just wanted to search the source code for various things. The debugger gave me a convenient way of doing this. By loading the program (but not running or stepping it), I had one all-inclusive source file to search and optionally save to disk. In addition, the program map (the tree-like structure in the upper left pane) made it easy to jump around between different procedures. Since I didn't want to run the program, I just cancelled SQRW by right-clicking on its button in the taskbar.

Even the (limited) syntax highlighting makes reviewing a program much easier. This is especially helpful in quickly identifying commented-out code or code made inactive by #IFDEFs. There are editors that can do this also, at least for comments and statement keywords.

Even before a new program is ready, I often load it into the debugger to check quickly for syntax errors. Instead of chasing down "error on line 1234" messages from SQRW (which file is that?), this lets me see immediately where an error is located.

It's also become my habit to test new programs by stepping through them slowly the first few times. As each bug is encountered, I can fix it quickly and then try again. Eventually I'll have enough confidence in the program to just let it fly under SQRW. It's also a good idea to check the Code Alerts box for any suspicious code the debugger may have found.

If you're working in a mixed Windows/Unix environment, it can be tricky to do these things on the Windows side. For example, a program might open a file using {FILEPREFIX} or other constants. If these use the Unix file path convention, you won't be able to run the program under Windows. There are a couple of ways of dealing with this. First, if the program builds a file name in a string variable before opening the file, you can just set a breakpoint on the OPEN statement and change the variable before the OPEN executes. Another way is to create a version of SETENV.SQC for your own use, overriding whatever you need. Be sure to save that version in a separate folder on your C: drive and then specify that folder as the first #INCLUDE folder in the debugger. That way it, and not the regular version, will be used during your debugging sessions.

Until next time...