| Debugger Tricks | KEVIN RESCHENBERG
01-04-2006 |
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.
|
