A place to list and discuss VFP Debugger issues and problems
Having trouble with your program? Think it's time to pull out the debugger? The debugger is your friend . . . sometimes. Other times, it's on the enemy's side.
Debugger can cause spurious screen refreshes
This can be loads of fun when you are debugging your refresh code. In one case, I think it was the activate event from switching from debugger to app. In another, my problem was not having enough .refresh() calls. This was a pain to debug since my program worked fine UNDER THE DEBUGGER due to said spurious refreshes.
A screen event can cause great fun, too. There you are with set step on when suddenly, you click on an app button. Oh, no! No more tracing. This is a real bother if the button is calling the wrong code and you want to find out what it is calling. set step on everywhere, anyone?
My latest escapade has to do with .keypress(). I just spent the better part of an hour today trying to get some code working again. Silly me: I thought the proof-of-concept was great and now I would put in the fullblown code. Something broke. Despite having a set step on at the beginning of .keypress(), it whizzed through through the code without stopping. This made it very difficult to debug.
Debugging Word automation
If you instantiate Word.Application and open any of the debug windows in VFP 5, you will GPF. -- Rick Hodder
Switching between application and debugger causes lost/got focus events to fire
Most of my VFP work is done using F1's Visual FoxExpress, so my technique
is tailored around that environment, but you should be able to apply this to any environment.
Switching between the VFP application (App) and the debugger causes App's lost/got focus events to fire, which takes me away from the part of App that I wanted to use the debugger on.
This will suspend the app, and bring the debugger forward.
- Find some variable that gets set in the code you want to debug. lnReturn
- Open the debugger and run (not step or trace) App, or run App and open the debugger if App has a DEBUG option (faster).
- Switch to the debugger, enter into the watch window "lnReturn" and set break a point on it (double click in the left margin, you will see a red dot)
- Switch back to App (alt tab works best, otherwise you may “click” on something)
- Do App thing that will cause the app to trip the breakpoint.
Use Debug Frame
If you run the debugger in the Debug Frame, the got/lost focus events won't fire. You'll also be able to use the menus -- Craig Berntson
The debugger's menus don't work
They're just busy, click longer.
They do, but they are just really busy. It seems that the debuggers menus are related to the “VFP menu engine” and anything, repeat, anything you do with the menus causes all, yes all, of the skip for expressions to be evaluated. If they call code, the debugger starts gets involved with the code, and it all goes really slow. What this means to you is: Hold the mouse click down until the menu drops. You can see an example of this by running the little program below, and doing “menu things” – click on a menu pad, click on the same menu pad, click on the menu bar (not on a pad), close and open the command window (ctrl-f4, ctrl-f2) switch between VFP and the debugger.... I find it amazing how many things will cause lDsp() to be called.
set proc to (program())
DEFINE PAD mpad1 OF _MSYSMENU PROMPT 'test' skip for lDsp( "mpad1" )
ON PAD mpad1 OF _MSYSMENU ACTIVATE POPUP mpop1
DEFINE POPUP mpop1
DEFINE BAR 1 OF mpop1 PROMPT 'test1' skip for lDsp( "Bar1" )
DEFINE BAR 2 OF mpop1 PROMPT 'test2' skip for lDsp( "Bar2" )
function lDsp( tcStr )
I've had similar problems when trying to use the mouse to pull down menus in the debugger while running codebook applications. However, if you use the keyboard equivalent (ALT-whatever) it works fine.
Improve menu speed
See my tip in the VfpDebugger main topic on
SET TRBETWEEN OFF. That will also improve menu execution speed since the executed code won't be displayed while trying to access the menus. -- Mike Yearwood
Often closing the debugger while the app is still running with cause the dreaded GPF 000005.
Hover crashes debugger
Hovering the mouse over a variable or expression will give you a tool tip with the value. However, if the expression has items with _access methods and you hover the mouse over it, this will tend to C5 the debugger. So, watch where you put your mouse.
Typing into breakpoint window does not work
I just talked to the Microsoft VFP people about the Debugger and VFP 7. Seems that the tried and true function of typing a function, method or procedure name in Breakpoint Location field now does nothing! In VFP 6 this would cause execution to stop on the first executable line. No more. Microsoft knows about this and it is a bug. Bad news there is no real work around other than SET STEP ON. Putting a breakpoint in the code doesn't seem to work at least for methods in VCXs (at least I haven't been able to do it), and the the bad news is that according to Microsoft, this probably won't be fixed until VFP 8.
Actually, the solution to this one is specify the name of the method followed by a comma and the line number of the first executable line, like:
But I sure they hope they fix it soon. It is a PITA.
As for setting a breakpoint in a method, that does work. However, my experience is that it only works once the class has been saved at least once because the breakpoint includes the file name. -- Tamar Granor
Next: VFP Debugger Setup Options
Contributors: Carl Karsten, Rick Hodder, Michael GEmmons, Mike Yearwood
Category VFP IDE Category VFP Debugger
( Topic last updated: 2013.12.02 03:13:12 PM )