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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
