Difference between Step over and Run
Jim Hurley
jhurley at infostations.com
Tue Nov 22 10:50:43 EST 2005
>
>Jim Hurley wrote:
>>> I have noticed in the debugger that there is quite a difference in
>>> time of execution between
>>>
>>> Step over
>>>
>>> and
>>>
>>> Run
>
>I think this is because of the traceDelay. When you are debugging, every
>step includes a pause equivalent to the traceDelay setting. When you
>"run", the engine goes back to full speed.
>
><snip stuff>
>
>> Moral: Even though the screen is locked by script, it is not locked when
>> running the debugger, UNLESS you Run to the next line. And it will run
>> though the window work much faster if you unlock the window.
>>
>> Unless someone recognizes this as a known bug in the debugger, I will
>> submit it.
>
>I believe this behavior is intentional. The assumption is that during
>debugging you always want to see what is happening. There have been
>innumerable instances where I was happy it worked that way, because I
>could see the screen change during debugging without altering my code
>temporarily.
Jacque,
Yes, I understand and appreciate this facility.
To understand my point you need to run the following script:
on mouseUp
put "" into field 1
lock screen --Try with and without this line.
doWindowWork --With a break point maker here
beep
end mouseUp
on doWindowWork
put the ticks into tStartTime
put 1 into field 1
repeat 100
add 1 to field 1
end repeat
put cr & the Ticks - tStartTime after msg box
end doWindowWork
First, step over "doWindowWork" with the screen unlocked. You see the
values in field 1 change (rapidly) from 1 to 100. It take about 30
ticks. This is the way I would hope the debugger would work in this
case.
Next, step over "doWindowWork" with the screen locked. You again see
the values in field 1 change from 1 to 100, but this time very
slowly--it takes about 1000 ticks.
In both cases you "see what is happening" but at a very different
pace. Many times in the stack I was working on, there was so much
field work being done that "Step over" is not feasible with the
screen locked--taking several minutes to execute. (The screen was
locked precisely because of this field activity.)
The work around is to strike out the screen lock line in the script.
A bit of a nuisance, requiring one script without the debugger and
another with the debugger. Or better, if viewing the field changes is
not important, then running to the next line of code.
My suggestion would be that the debugger would reveal the field
changes at the same pace with and without the screen lock when
stepping over the line which effects the field changes.
Sorry; long winded and perhaps a point too fine. And I'm afraid I
confused the issue with the subject line of this post.
Jim
More information about the use-livecode
mailing list