A topic devoted to VFP debugger breakpoints
There are many ways to set breakpoints:
- Right-click on a line of code while editing method code in the form or class designer or in a PRG and choose "Set Breakpoint" (applies to Version 6.0 with service pack 3)
- To disable/enable 'historical' breakpoints, select Tools/Breakpoints from the debugger's menu. You will see a list of break points in the bottom pane. Click on the one you want to disable (or enable) and either click on the checkbox or the disable/enable button.
- In the trace window, click on the margin beside a line of code. This will produce a red dot where the debugger will stop next time it passes this line. Double-click on the same line again, and the breakpoint will be cleared.
- In the trace window, you can select any line of code, then rightclick - Run To Cursor. This is a quickie breakpoint that's very useful for, for example, stopping after a loop terminates or at some other immediate juncture without setting a permanent breakpoint.
- In the VFP Debugger Watch Window (Watch Window) you can click in the margin beside a watch. This will display a red dot that tells you VFP will break the next time the watch's value changes.
- When the code
SET STEP ON is encountered, execution suspends and the VFP Debugger Trace Window (trace window) opens.
It should be noted that breakpoints only trigger if the VFP Debugger Trace Window is already open (meaning they can be left in compiled code without breaking it, not that I recommend that). SET STEP ON, however, will always stop code, but if left in compiled code could cause an abnormal stop. Dan LeClair
- By specifying a condition and making it active in the Breakpoint Dialog (pictured below). You invoke this window by hitting the Breakpoint dialog button on the debugger toolbar. Note that
ACTIVATE WINDOW Breakpoints from the command window does NOT work.
Cool tip: The “TimeBomb”:
minute( datetime() ) in the watch window with a break set. Helps deal with endless loops. Every minute the value will change, and that will cause the debugger to suspend the current app, regardless of what it is doing. Example: You want to examine the code that called messagebox() which prevents debugger events, like suspend. Set timebomb, run code that calls messagebox(), wait for minute to roll over (task bar clock), exit messagebox(), program halts on next line.
Set a breakpoint when a desired function starts, put
"mycode" $ lower( program() ) in the watch window and set it to break on change. It will switch from .f. to .t. when "mycode" starts executing, and the program will suspend. "mycode" can be a function name, method name, vcx, or most any way that code is named.
Also, if you want to break on a specific object's method, such as Init(), you can refine the trick above to read
"myobjectname.init" $ lower( program() ). This will avoid breaking on every single Init() which fires.
You can also add this breakpoint with the breakpoints dialog by specifying myobjectname.init in the Location field and pressing the Add button.
If you want to break when an expression changes, not when it goes out of scope, use an IIF with expression = the current value, and a dummy expression, and a constant so that the only time the whole thing evaluates is when the value actually has changed. like so: iif( nCtr = 5, uDummy, .t. ). this expression will not break as nCtr goes in and out of scope, but will cause a break when nCtr changes from 5. Similare to scope is data sessions. To watch for a change in field state:
iif( set('datasession')=3 and !eof("qt3"), getfldstate( -1, "qt3" ), "111" ) -- Carl Karsten
See also: VFP Debugger Call Stack Window
Category VFP Ide Category VFP Debugger Category 3 Star Topics
( Topic last updated: 2001.10.05 02:33:11 PM )