LINE POINTER IN DEBUG MISBEHAVES

[IlyaRabyy]

Colleagues,

That sometimes the record pointer in Debugger stops at the code's line before the stop point (e.g. SET STEP ON) is a well known fact.
However, I haven't seen this pointer shown "stopped" at a code's line way down after the stop point!.. That is - until now. :-(
In my case, I have SET STEP ON, say, on line #100, and the Debugger does stop the execution at that line, but it shows the line pointer stopped at the line #, say, 450...
This always happens after the execution passes CREATE CURSOR command (somewhat lengthy this one, 45 lines in the code).
If you ask how I know that the Debugger has actually stopped where it's supposed to, it is by checking the contents of the memvars whose values are assigned in the code below that my stop point.

Have anyone encountered such faulty behavior of Debugger, and what can be done to fix it?

AHWBGA!


Regards,

Ilya

 

[JRB-Bldr]

From time-to-time I have also seen mysterious Debug line execution 'Stops' occurring.

Generally it is after I had placed one or more Breakpoints in the code and then Cleared them via the VFP Top-menu - Tools - Breakpoints - Clear All.

When that is occurring, having the Debugger 'stop' at any non-Breakpoint point before or after an intentional SET STEP ON would be no surprise.
The same thing that caused the mysterious 'stop' Before the SET STEP ON is obviously causing the 'stop' After the SET STEP ON.

I assume that despite my having Cleared All of the Breakpoints and doing a new Compile of the code there is something 'stuck' somewhere that is causing this - although one of the gurus are welcome to 'enlighten' me on this.

It may be annoying, but it is not any real problem.
Generally, after some time, the problem goes away.

Good Luck,
JRB-Bldr

 

[IlyaRabyy]

Thanks, JRB!
Did all that what you recommended (clear stop points) several times - didn't help, even after rebooting the system.
But (after struggling with it for more hours than I would like to) I managed to find the "culprit": the CREATE CURSOR command was, apparently, way too long for the Debugger to handle. So, I "cut" couple dozen fields from that command and put them back in afterwards with the equal number of ALTER TABLE ADD COLUMN commands - and this did the trick: Debugger now works properly.

Not The Solution, rather A Workaround, but work it did. ;-)

P.S. I wonder, though, why there's no mentioning of the command string's size limit for Debugger in the VFP's Help...

Regards,

Ilya

 

[vgulielmus]

Please check this thread Link
You can use a EXECSCRIPT() instead

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

http://praisachion.blogspot.com/

 

[Olaf Doschke]

I only know Tamar sometimes posted, that breakpoint info is stored in PJX/PJT data, especially for PRGs (as there is no section in these files to store breakpoint info, they are pure ASCII text files, 100% your code). So things somehow may get out of sync, the info the debugger shows and the breakpoints the runtime sees may differ.

Since several versions you can compile SET STEP ON without getting "Option not available" error at runtime in an EXE, the line is simply ignored without VFP9.exe and its debugger available. Therefore I like to use that, in case of unconditional break points. The break piont form does offer much more, even breaking anywhere, when some condition get's true or some expression changes it's value. You might also check, if you have defined some breakpoint like that without a defined position in source code.

Anyway, the plus of SET STEP ON also has a minus: You can't remove that break ponit during debugging, but you could put it into an IF about some condition you can control during debugging, eg IF glBreakpoints, which you set .T. at the start and then during debugging set .F., obviously.

Bye, Olaf.

 

[Mike Lewis]

Something that puzzles me:

People are always being advised in this forum to use SET STEP ON as a debugging aid. I've never understood why. I haven't used that command myself since FPW 2.x.

It seems to me that setting a breakpoint - by pressing F9, or double-clicking in the Debugger - is not only faster and simpler than typing a line of code, but has the advantage of being easier to remove when you no longer need it - especially when you want to remove them in bulk. Instead of seeking out and manually deleting each SET STEP command, you can simply "clear all breakpoints". And if you forget to remove them when you build the executable, they are simply ignored. It's true that SET STEP ON no longer causes an error in EXEs, but it is still present to clutter the code and distract attention from the main functionality.

I'm not trying to persuade anyone to change their habits, but if SET STEP ON has some advantage over setting breakpoints, I'd be interested in hearing about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, I've had enough similar cases of normal breakpoints either not working, or working more or less lines off their position. I've never had this issue with SET STEP ON.

Bye, Olaf.

 

[Mike Gagnon]

http://www.baiyujia.com/vfpdocuments/f_vfp9fix5.asp

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[JRB-Bldr]

More often than not, I do use SET STEP ON because a Breakpoint will only stop execution if the TRACE window is already open. If it is not, a Breakpoint will do nothing.
SET STEP ON will force the opening of the TRACE window and pause execution even when I forgot to open it.

JRB-Bldr

 

[Mike Lewis]

I've had enough similar cases of normal breakpoints either not working, or working more or less lines off their position.

I can't say I've had that problem very often. But I can see why you might prefer to avoid breakpoints if you did.

More often than not, I do use SET STEP ON because a Breakpoint will only stop execution if the TRACE window is already open. If it is not, a Breakpoint will do nothing.
SET STEP ON will force the opening of the TRACE window and pause execution even when I forgot to open it.

That's a good point. But it works both ways. There might be times when you don't want it to pause execution, but you don't want to delete the breakpoint either. In those cases, you can simply close the Trace window. Also, with a breakpoint, you can temporarily disable it without deleting it. Also, you can set or clear breakpoints from within the Trace window, while the program is executing. You can't do that with SET STEP, as it would mean editing the source code, which in turn would mean cancelling the execution.

However, I accept that this is partly a matter of personal taste, so I won't try to persuade anyone to change the habits of a lifetime.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I only know Tamar sometimes posted, that breakpoint info is stored in PJX/PJT data, especially for PRGs (as there is no section in these files to store breakpoint info, they are pure ASCII text files, 100% your code).

I'm pretty sure I've never said that. AFAIK, breakpoint info is stored in the resource file. You can save your Debugger set-up to a file and restore it (only, I think, if you use the Debugger frame).

I'm with Mike on SET STEP ON. Rarely, if ever, use it. I set breakpoints in code windows or in the Debugger. To me, the fact that a breakpoint doesn't work if the Debugger is closed is positive, not negative.

I haven't seen the problem that started this thread. I have seen cases of "phantom breakpoints" and have never figured out why they happen.

Tamar

 

[JRB-Bldr]

I haven't seen the problem that started this thread. I have seen cases of "phantom breakpoints" and have never figured out why they happen.

Actually my interpretation of the original post was indeed about "phantom breakpoints" mysteriously halting the execution of the code somewhere (when the TRACE/DEBUG Window is open) Before or After the intended break at SET STEP ON

JRB-Bldr

 

[TamarGranor]

When I say "phantom breakpoints," I mean that VFP continues to break at lines which used to have a breakpoint, but doesn't anymore.

Tamar

 

[DSummZZZ]

My 2 cents:
I have this same 'phantom breakpoint' issue even when I try and clone a form to create a new form.
For example, I open form1.scx (which has a phantom breakpoint), do File->Save As form2.scx. Change the 'Name' property to 'form2', and form2 will have that same phantom breakpoint.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

Nice finding, Dave!

we may assume from that, the info about breakpoints is stored in several places, both in foxuser and within the source code or object files (or object memo). I may be wrong about PJX/PJT, as Tamar didn't confirm what I thought came from her, but redundant stored breakpoint info would explain, why the editor and debugger act differently. The highlighting of a breakpoint is perhaps reading the info from foxuser and at runtime it's still found in the SCT file, therefore it also exists in a form copy.

Bye, Olaf.

 

[Mike Lewis]

I may be wrong about PJX/PJT, as Tamar didn't confirm what I thought came from her

I am supremely ignorant on this point. But I would be surprised if breakpoints were stored in project files. After all, any file that contains code can have breakpoints. But not every file that has breakpoints is stored in a project.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I'm reasonably certain that breakpoints are stored only in the resource file, except for the ability to store a Debugger configuration to later be restored.

Tamar

 

[Dan Freeman]

Unless they've changed it since VFP5, debugger configurations are stored in the registry. I wrote about saving .REG files and using them to restore debugger configurations when I was at IMG around the turn of the century.

That didn't cover breakpoints. But I'll tell you I've experienced phantom breakpoints between restarts occasionally and I haven't used the resource file as a regular thing since it got a little flaky in FPD2.0.

 

[Mike Lewis]

Unless they've changed it since VFP5, debugger configurations are stored in the registry.

Well, I've just done a careful check on all the VFP-related nodes in the Registry - both in HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE. I can't see anything relating to the debugger, and especially not breakpoints.

On the other hand, I can clearly see breakpoint information in Foxuser. Each breakpoint is stored in a record whose ID is BPOINTS. Here is some typical content of that record:

BGCFGVERSION=4
BPMESSAGE=ON
BREAKPOINT BEGIN
TYPE=0
FILE=c:\fox\apps\main.prg
LINE=88
DISABLED=0
EXACT=0
BREAKPOINT END

Correction: It's not true that each breakpoint is stored in a single record. There is one BPOINTS record, containing all current breakpoints. Each breakpoint is bracketted by BREAKPOINT BEGIN and BREAKPOINT END. But my main point is that breakpoints are stored in the resource file, not the registry.

Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Now the big question: I just SET RESOURCE OFF and created a breakpoint in a new PRG file. It doesn't show up in Foxuser, but it works.

Bye, Olaf.