>>Interesting comments. I think we're about to "branch" into a discussion of coding styles vs. using the debugger, per se.
>>
>>Call it massive hubris, call it what you will, but I simply don't run into many bugs caused by me.
>>
>>I started programming in an industrial environment where line time was $7,000 per hour. If what I did caused problems, I heard about it real fast. Subsequently, by habit I learned to "battle-harden" my code.
>>
>>Basically, my routines assume that nothing will work. I estimate I spend over 90% of my coding time stamping out possible error-causing conditions, usually before even starting on the code that actually does useful work!
>>
>
> That still doesn't account for logic errors or errors in your error checking ;-) Being able to step through the code and see what the computer is actually doing without having to add a ton of extra coding (ie. printing variables, "I'm Here!" messages, etc.) saves me a lot of time.

Agreed, everyone, me included (:-\) runs into logic errors of various kinds. The main point I wanted to make is that, for me, it's better to write code that can recover gracefully from a wide range of unexpected conditions, than to rely on the debugger to trace code under "normal" conditions and give me a warm, fuzzy feeling that my code is "OK".

>
>>Again, maybe it's hubris, but I find that with my own code (and even with a lot of other people's) I can simply read it, and understand what it's doing.
>>
>
> That's where I normally get into problems. I code things thinking I know what it's doing or going to do, but when/if it doesn't it's really helpful to be able to just step through the code and view all the variable changes as they take place. I don't have to rely just on my brain to make sure I'm not forgetting or overlooking something. Why waste 15 minutes analyzing the code when 2 minutes of stepping through it with the debugger will give me the same answer?

I'm sounding like a broken record, but I just don't run into many bugs. As a consequence, I haven't made much use of the debugger. I'll freely admit I know very little about it. I can trace code and watch variables in the Watch window; that's about it.

I modularize my code so that no single method gets very complicated; as a result, the offender is easy to spot. In the vast majority of cases, my logic errors are the equivalent of typos - what I call CVLs (cerebral vapour locks). Things like reversal of conditions in an IF...ELSE...ENDIF. These are easy to spot, or diagnose with a WAIT WINDOW.

In contrast, my experience with the debugger means I have to insert a strategic SET STEP ON, then type in the appropriate variable names in the Watch window. There seem to be an awful lot of circumstances where the debugger simply doesn't work - like if you're trying to look into form .Activate(), .GotFocus() methods etc. Features like "run to cursor" or "Step through" do not always complete. If your app throws a serious error with the debugger running the VFP session is often blown entirely - try to get out of 10^n "goApp is not an object" dialogs, with the debugger trying to bounce up each time, before the VFP session runs out of memory. Thank god for NT and its ability to cleanly blow it away. Simply put, with the kinds of SERIOUS errors I run into, the debugger is (has been) more of a hindrance than a help.

I guess I expect the VFP debugger to be more of a true VFP emulator than it is. If it could give a VFP app the same sort of sandbox that NT gives to a Win32 app, it would probably be reliable enough to help me with the "toughies" I sometimes run into.

Having said ALL that, I have had a very few circumstances where my WAIT WINDOWs were not enough, and the debugger was invaluable. But, the operative phrase here is "very few" - little need to use it, little need to learn to use it well. That I freely admit.