How do set set and use BREAKPOINTS??

[opticalman]

I am using VFP8.
I am setting BREAKPOINTS visually, by clicking the "gray left margin" and placing a red dot where I want the break.

My problem is that the code will not break out every time. My most common experience is for it to break the first time I run it, but never again. Am I missing something basic???

Jim Rumbaugh

 

[DSummZZZ]

Unless you're clicking on the 'Clear Breakpoint' icon (the hand with the red X on it), you should be getting breaks every time you hit that line of code.

If that isn't the case, are you sure you're hitting that line of code?.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

Which window are you using to set the breakpoint? The code editing window? The Trace window?

One thing I have run into is that setting a breakpoint before I've saved the code once tends not to work very well.

Tamar

 

[JRB-Bldr]

Assuming that you are testing your code from the Command window, you should enter ACTIVATE WINDOW TRACE.

Then go back to your Command windows and launch your program.

With the TRACE window open, the program will stop at your Breakpoints. Note - your TRACE window is a separate windows and is sometimes in the background behind your VFP window. So if your program appears to stop executing, bring your TRACE window to the front to see what is happening.

Also - you can set (toggle) the Breakpoint in one of two means. If you have your code halted in the TRACE window you can merely place your cursor on the intended line and press the Space bar. A Red dot at the left of the line will indicate the Breakpoint is set.

The other way is to set the Breakpoint in the code itself during the Edit process. Place your cursor on the intended line and then right click. Choose Toggle Breakpoint and the Red dot will appear (or disappear).

But regardless of how it is set, it will only halt if the TRACE window is open during development execution.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

you should enter ACTIVATE WINDOW TRACE.
....
it will only halt if the TRACE window is open during development execution.

Actually, I'm not sure if that's true. If you set a breakpoint in a form or class, VFP should open the debugger (and trace window) when it hits the breakpoint, even if the debugger was not previously open.

That's not the case with breakpoints in a PRG.

Jim, if you're sure the breakpoint isn't firing, try setting it on the next or previous line of code. I don't know why, but I sometimes see breakpoints failing to fire on certain commands. Sometimes, just clearing it and setting it again does the trick.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olaf Doschke]

I stopped using visual breakpoints, as I found them to not wor reliable. But thanks to you and Tamar and Mike, I now know more about why they sometimes don't work. AFAIK the foxuser.dbf is used to store break point locations in prgs or methods in the data field in a binary format. Setting break points before saving (and compiling) a prg might be an issue, true.

What works very realiable is the set step on command. The problem with that is when using that within a loop you can't turn the breakpoint off in the debugger. The other problem is, when compiling set step on it causes error 1001 "feature is not available", in the EXE. So you have less control and need to be careful not to forget one of them.

The better SET STEP ON is ASSERT .F., as you can switch it on and off with SET ASSERTS ON/OFF. But breakpoints aren't bad in general, as you can not only break in a certain line, but when an expression is .T. or everytime an expression is changing. I'm using a mix of ASSERTS and this kind of breakpoints.

Bye, Olaf.

 

[mmerlinn]

I gave up on breakpoints, tracing, & stepping long ago. Instead, in FP2.6 I have a short function I insert at my breakpoints. When fired, a window pops up with the desired info in it.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[Olaf Doschke]

Hi mmerlin,

you're missing the benefit of changing variable values and setting next statement. Sometimes you can fix a minor error by hand and let it run the rest, especially if it took some time until an error occured.

Of course that also requires a decent errorhandler, that can take you to the debugger if _vfp.startmode=0 and a dialog (messagebox), that asks you, if you want to run the debugger.

Bye, Olaf.

 

[opticalman]

Thanks to all of you.

Like Mike, I thought the debugger would fire and open without issuing the command ACTIVATE WINDOW TRACE. And may I add that sometimes it did open, but that was the unpredicatable part. Per the suggestion from JRB-Bldr, I have confirmed that ACTIVATE WINDOW TRACE will cause the break to act the way I expected and with out the command the break does not happen.

I consider this problem solved.

I have enjoyed the many comments on this subject

Thanks
Jim Rumbaugh

 

[mmerlinn]

Olaf:

Thanks for the insight. I quit using those built-in debugger routines several years ago because I could never consistently make them work for me.

I don't know whether you used FP2.6 or not, but many things available today were not available then. And what is available I got frustrated with - I simply had too many problems with them.

So I wrote my own function that I use for breakpoints. I pass it the values I am tracking, and when it fires, everything I need to know pops up in a separate window where it stays open until I click the mouse. It then closes and the program resumes running unless I break out of it first.

I don't remember (if I even knew) about SETting next statement. And I don't see any value in changing variable values on the fly. If I want to run a set of values through a function, I just isolate the function in a mini-program and run the desired loops to make sure the output matches the input.




mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[TamarGranor]

MMerlin -- if you haven't worked with the Debugger that was added in VFP 5, you should spend some timing getting to know it. You might want to read my article on the subject at:

http://www.tomorrowssolutionsllc.com/session_materials.htm

Tamar

 

[Olaf Doschke]

Add to useful support of debugging:

* add these in the main.prg (which is always on the callstack)

on key label ALT+F12 oObjectUnderMouse = sys(1270)
* have loObjectUnderMouse in the watch window
* hover over an object of interest and press ALT+F12
on key label ALT+F11 release oObjectUnderMouse
* release the variable. Otherwise this could cause
* the one object reference preventing an object release/destroy.

on key label ALT+F10 ProcDebug()
on key label ALT+F9 ProcShowcommand()

Procedure procDebug()
   Set && shows window datasession
   Set  Step On && opens debugger
EndProc

Procedure procShowcommand()
   Show Window "command"
   Move Window "command" Center
EndProc

When browsing tables use the NOCAPTION and NORMAL clause of the BROWSE command, otherwise windows will fit on the active form.

Bye, Olaf.

 

[Olaf Doschke]

perhaps nest the key definitions in IF _VFP.StartMode=0 ... ENDIF, otherwise this could be misused as attack on the sourcecode especially ALT+F10 and especially if the EXE is not encrypted and debug info is compiled into it.

 

[Mike Lewis]

Mmerlinn,

I have to agree with Tamar. The debugger is an excellent tool, and it will definitely be worth your while investing a little time in overcoming whatever difficulties you had with it.

I'm not denigrating your own functions. No doubt they work well, and I'm not suggesting you abandon them. But it seems a pity to turn your back on all the other features that the debugger offers.

Note that my comments refer to the debugger in current versions of VFP (5.0 and later). If you are using 2.6, then that's a different situation entirely.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk