×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

debugger not stepping through code step by step

debugger not stepping through code step by step

debugger not stepping through code step by step

(OP)
I have just recently started getting an issue where the debugger does not step through the code line by line, but instead only stops where "SET STEP ON" occurs.
I set "SET STEP ON" at the point I want to check, then press F8 to step the code. However, the code runs without stopping/stepping at each line, just like what happens when the resume button was clicked.


Anyone seen this before?

RE: debugger not stepping through code step by step

I wonder if this is because the debugger is seeing out-of-date code.

You could try doing a COMPILE of the program before running it in the debugger.

Just a guess.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: debugger not stepping through code step by step

(OP)
I don't know what caused the issue, but is ok now.

Alastair

RE: debugger not stepping through code step by step

(OP)
Ok an update:
I am still having the issue.
It seems to be occurring in timers, but I am having other issues as well

The another issue is with pemstatus anywhere on a form
In the console the command works as expected:

CODE

x = pemstatus(_screen,'oLoadingForm',5)
? x 
x will show as .t.


But the following always triggers false

CODE

IF pemstatus(_screen,'oLoadingForm',5)
&& Do somthing
ENDIF

My programs have pemstatus used extensively just like the second code example with no issues. But now it does not return a .t. value when clearly the value is .t.

I changed one instance to the following:

CODE

IF pemstatus(_screen,'oLoadingForm',5) = .t.
&& Do something
ENDIF

And this time it registered the .t. and the code in the IF statement executed





RE: debugger not stepping through code step by step

I can't suggest anything regarding your PEMSTATUS() code. But you also mentioned timers. Using the debugger on code in Timer events nearly always causes problems. It's something I have always avoided.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: debugger not stepping through code step by step

Not sure if you're just lucky. I don't know enough about the whole situation, but doing some guesswork

oLoadingform - is that a form object existing while a form loads, removed from _screen afterwards? It could also be an object loading a form, but is it temporary only?

Are you checking pemstatus(_screen,'oLoadingForm',5) within a timer?

Well, then the timer events might occur before and after a form loaded, as simple as that. Loading of a form can be quite fast, also the timers aren't very precise and any code execution might queue timer events until after the code execution finishes and VFP becomes idle again, going into READ EVENTS mode and then timer events never fire during form load.

As said, there's very much guessing in this, but you might want to use BINDEVENTS here instead of a timer.

Without guessing, I can assure you it never is a problem to let the IF branch execute on a TRUE condition IF bExpression and it never needs IF bExpression=.T. to get there. Or shorter bExpression=.T. would never differ from bExpression itself, even if you would consider bExpression could be NULL. PEMSTATUS(...,5) can never be NULL, but even if it could, NULL=.T. is NULL just like NULL alone is. So bExpression=.T. always is the same as bExpression. Unless bExpression isn't logical/boolean, but then that would throw type errors every time.

To prove this in short just actually use a variable bExpression and set it to the three possible values .NULL., .T., and .F. and then check whether bExpression=.T. and bExpression itself can ever differ, or specifically whether bExpression = .T. can ever be .T. while bExpression itself is not .T., but .NULL. or .F. - you'll see it can't.

CODE -->

bExpression = .F.
? bExpression=.T., bExpression
bExpression = .T.
? bExpression=.T., bExpression
bExpression = .NULL.
? bExpression=.T., bExpression 
This outputs three lines, each displaying the same boolean value twice.

Now the only remaining thing to know is what happens if an IF statements condition is NULL.

CODE

If .null.
   ? 'ifbranch'
Else
   ? 'elsebranch'
Endif 
The answer is in case of a NULL value of the IF condition, the else branch becomes executed. This could be relevant if your overall IF condition involves more things that could also become .NULL. and would therefore explain that the if branch doesn't execute.


But in itself adding =.T. to an already evaluated expression with no further terms ANDded or ORed into the overall condition makes no difference whatsoever. So the only reason you had success with adding .T. is luck to catch one instance where the condition became .T., which you'd also have seen not adding =.T.

Well, and as a quintessence of it all - describe what you're doing more precisely to get better analysis and advice. But, really, you've made no difference from what I can see, the condition must be more complex and then it may become explainable.

Chriss

RE: debugger not stepping through code step by step

Breakpoints within timer events are hard o do, one thing I said recently is that you do yourself a favor with debugging timer events with breakpoints, if the first line of code of a timer is This.Enabled=.F.

Then never forget to set Enabled back to .T. at the end, including to do so when you Return anywhere in a branch of conditionally executed code. But when that is established this timer can't happen within the debugging of it. You also have to consider parallel timers, though. And therefore the debugger has a setting to ignore all timer events in the trace window. That means other timers happen and run without that code execution being shown in the debugging process in the trace window.

But if further timers influence what you're debugging, that can become impossible to debug, as the factor of you slowly stepping through code could differ from the actual runtime execution. So multiple timers are problematic to debug even with that precaution and using the debugger setting about timer events. Then it becomes more valuable to do coverage logging of what happens.

Chriss

RE: debugger not stepping through code step by step

I wonder what you did.

Have you put something like that into your base form class?

CODE

AddProperty(_screen,"oloadingform",THIS) && start of Load event
...
RemoveProperty(_screen,"oloadingform") && end of Init event. 

And are you trying to catch all forms starting with a timer observing the existence of oloadingform?
Then it would be simpler to add to the base code of forms, wouldn't it?

What is really your goal, in plain English?

Chriss

RE: debugger not stepping through code step by step

I've had this happen before, usually when I'm debugging timer code.

The only reliable way I've found as a workaround is to set a breakpoint on every line you want to stop on. Then, when you single-step, it breaks at those lines.

Several years ago I had some code I couldn't debug for that very reason. Was driving me nuts. I finally just out of desperation set a breakpoint on every line to see what happened, and it worked. I've used it a few times since then.

--
Rick C. Hodgin

RE: debugger not stepping through code step by step

Quote (Chriss)

Breakpoints within timer events are hard to do, one thing I said recently is that you do yourself a favor with debugging timer events with breakpoints, if the first line of code of a timer is This.Enabled=.F.

Another thing to do is create a property off _vfp that is a global timer activity state, which can be tested by every timer to see if all timers should be suspended.

It would be nice if VFP had a feature like SET TIMERS ON|OFF|SUSPENDED|AUTO so that you could debug them, and it could automatically enter the SUSPENDED state when you have a breakpoint in a timer if it were in AUTO mode, and when resuming it would go back to normal.

--
Rick C. Hodgin

RE: debugger not stepping through code step by step

One option when dealing with timer stuff is to lace your code with DEBUGOUT commands and, if necessary, turn on event tracking, so you can see what's happening without relying on breakpoints.

Tamar

RE: debugger not stepping through code step by step

(OP)
Thanks
I have modified my code so the timer only calls the next event and the validation is done in the next event, not the timer.
This enables stepping through the code in the next event as per normal.

With thanks
Alastair

RE: debugger not stepping through code step by step

It seems you don't understood this option:


If you have this off, the debugger will ignore displaying timer events in the trace window of the debugger. Furthermore, even if you set a breakpoint that's ignored. But you can in principle debug timers within the timer event, if you check this option. No need to use a workaround.

Chriss

RE: debugger not stepping through code step by step

(OP)
Thanks Chris

Alastair

RE: debugger not stepping through code step by step

My usual practice is to execute the following commands at the point where I want to begin debugging.

SET ASSERT ON
ASSERT .F.

Regards
Gary

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close