Programming technique/discipline

[stevengraff]

OK, confession... I'm not really a programmer. Thank you WinBatch for the opportunity to not let that detail get in my way!

Here's my question/problem:

When refining my programs I sometimes move at a glacial pace, trying to ensure that I don't break my existing "known working" code. I do a lot of add-a-line, test-a-line type of work, ok, sometimes 3 or 4 lines at a crack. I use debug(1) to single-step through my code. Then, when getting ready to compile, I have the minor pita of having to scour my code (using ctrl-F) for left-behind debug(1) lines, because, after all, no one wants my end-users single-stepping through my code!

Is there another way? Or is this about as good as it gets? Suggestions most welcome and appreciated.

[Deana]

You have a number of options for [Debugging WIL Scripts]

WinBatch Studio is used to both edit and debug scripts. There are various ways to debug a script:

Experienced programmers who can write relatively bug-free code might just write a script and then hit the ââ,¬Å"Goââ,¬Â button and see if it works. If an error occurs, the line causing the error on it will be indicated and the current state of all variables displayed.

The rest of us will find that debugging a script is a more interesting process. We might write a few lines of code and then press the ââ,¬Å"Step Intoââ,¬Â button to step through the code one line at a time. As each line is executed the current state of all variables is displayed in a special ââ,¬Å"watch windowââ,¬Â.

Once large sections of code are bug free, it becomes rather boring to step, step, step through each statement. There are several different solutions to this problem. One is the ââ,¬Å"Step Overââ,¬Â button that can be used to execute entire sections of code in a GoSub or Call function. In addition there is a ââ,¬Å"Run to Cursorââ,¬Â hot-key combination (Ctrl-F10) and menu item that allows you to place the mouse cursor on a line and execute to that point. In this way, it is possible to avoid step, step, stepping through large blocks of code.

For serious debugging there are ââ,¬Å"breakpointsââ,¬Â. Breakpoints are useful where there is a large quantity of code and you are interested in debugging a specific section of it. To use breakpoints you click on a line of code and hit the ââ,¬Å"Insert/Remove Breakpointââ,¬Â button. A red square will appear next to the line indicating a breakpoint is active on the line. Next you would click the ââ,¬Å"Goââ,¬Â button. The script will start executing and will stop when it hits a line with a breakpoint. You may have several different lines with breakpoints.

Hope this helps

[stevengraff]

Wow... and none of that had anything to do with debug(1) statements...

[mcvpjd3]

The other option you could use is a debug variable...

debugger=1
debug(debugger)

and when you have finished set debugger=0 and all your debugging statements are now turned off

[stevengraff]

Thanks for that mcvpjd3.

My first reaction was that I wouldn't want to type that much (as compared to debug(1), but then realized I could use debug(x) just as well.

Another idea I've used is to activate debugging via a parameter, for compiled scripts, or an ini setting.

[Deana]

Yes a commandline parameter would work. Another method would be to check for the existence of a specific flag file. I prefer to use DebugTrace for debugging. For example:

Code (winbatch) Select Expand

;Debug with Flag File
;Turn on debugtrace if a file with same root but extension .dbg exists in same dir as script.
debugflagfile = DirScript():Fileroot(Intcontrol(1004,0,0,0,0)):".dbg"
if FileExist(debugflagfile) then DebugTrace(@on,DirScript():Fileroot(Intcontrol(1004,0,0,0,0)):".log")
message(0,0)


[stevengraff]

Another cool idea I've discovered for debugging compiled scripts...

I've taken to beginning each script with a z=0 statement, then, when debugging change the zero to 1 and insert a debug(z) statement where needed. When done, I just change the z back to 0; when really done I remove all the debug lines.

Then I compile the code and convey it to the customer in exchange for cash. Then the customer tells me it's not working right. How to debug that in situ? I've previously mentioned using a parameter with the executable at run time, or sticking something in the ini file, like debug = 1, but in both the examples I will have just taught my customer how to get at my source code. Being of the protective (mildly paranoid) persuasion, I see this as a bad thing.

So here's a cool solution I've found... just below the z=0 line, I've taken to using

   if IsKeyDown(@CTRL & @SHIFT ) then z = 1

99% of this kind of work, in my case, happens through remote assist shared desktop sessions, which a) do grok that I'm holding down those keys and b) obscure the method from the client. This line can be strategically placed in the script where needed, and/or, another option...

   if IsKeyDown(@CTRL & @SHIFT ) then debug(1)

And if that's not enough obscurity, I could add a password prompt using the askPassword command or a dialog asking for credentials.
         

[kdmoyers]

There is another debugging technique to try when working on programs that use complex dynamic dialogs and require careful control of focus.  In these cases, the Studio debugger itself interferes with the program.  Even Message popups can wreck what you are trying to observe.

The idea is to use the DebugData statement, which sends data to an outside debug viewer.  A free viewer is available from SysInternals called Debug View http://technet.microsoft.com/en-us/sysinternals/bb896647

A screen shot of it in action is attached.  Note that the debugview window is seperate from your program and needs no interaction.  It just displays a neat log of whatever the DebugData statements silently tell it. 

There's an oddity where the DebugData statement sends extra blank lines and stuff, but you can use the Filter feature of DebugView to clean that up.

$0.02
Kirby

[td]

You can also send the output of the DebugTrace function to an external debugger by specifying "*DEBUGDATA*" as the trace file name in the p1 parameter.