Please forgive me for saying so, but doing any kind of serious professional VFP development without the debugger is masochistic ;-) ( kind of like a doctor deciding XRays and blood tests are just too confusing ) That being said, I think you'll be delighted when you find what just skimming the surface of its abilities will give you.

First, try putting
set step on
dodefault()
in the load() of your form. That will bring up the Trace window as soon as the form is called. On the debug toolbar the tooltips will help you find the callstack. That should tell you what called the form. Ctrl F2 will bring up the command window. SET will give you the data window to look at your open tables and views. The icons to step over, into, out etc will make the trace window your friend. Try right clicking in the trace window and seeing the cool stuff you can do there, especially RUN TO CURSOR and SET NEXT STATEMENT ( a good way to skip over a line of code you know is going to blow up and type something in the command window that will work )

the locals window and watch window really beat wait statements for knowing the value of variables and properties as the app is running. And, even better, the values can be changed in the watch window.

One of my favorite tricks is to type ox=sys(1270) in the command window, but don't hit enter until the mouse is hovering over an object you are interested in. You will then have an object ref to that object. Put ox in the watch window and see what happens. (if you like it assign this to a function key in an OKL in your starter program so you only have to hover and hit F8 or whatever ) Also is nice to have a key that will suspend available.

Lastly, do consider investing a couple bucks in Nancy Folsoms book on debugging Foxpro apps. ( Hentzenwerke ) You'll be amazed.

I've been teaching VFP development for quite a while now and it is not at all uncommon for folks to be less than comfortable with the debugger but I haven't met one yet who wasn't delighted after getting a couple of the basics in the toolbox.

Good luck.





>I have never made much use of the debugger because it has always been a puzzle for me and I usually debug with my own wait statements. But I have a situation that I can't resolve with a wait statement.
>
>i.e. I have a form (lets call it form1) that should have the buttons on the previous form disabled when it comes up. I have issued disable button methods at every point where this form is called but the buttons will not disable. This is because the form is being called in some part of my code which I can't locate. So I would like to get the debugger to stop every time it bumps into this form.
>
>I have tried loading the form name into the debugger and nothing happens. I am now getting a second problem, when I bring up the debugger and click on the Debug pad, the "Do" row is disabled. I need to be able to get the "Do" enabled in order to load the debugger. Sometimes "Do" is enabled but not always.
>
>I hate this thing but I have no choice in this case, so if someone can help me, I would appreciate it.
>
>Mike Smith