Jim Hurley wrote:
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.
Right. What it looks like to me is that the screen is being locked and
unlocked after each command, to enable you to see what is happening
during debugging but to keep the the context of the lockscreen command
consistent with its normal, non-debug state.
For example, if you had a handler that checked the state of the
lockscreen before doing an action, that handler would fail if the
debuger kept the state unlocked while stepping through code. So, it sets
the lockscreen to false, executes a line of code, and then sets it to
true again so that the next line of code can correctly evaluate the
state. Drawing to screen is time-consuming, so it slows things down
considerably. I think this is the only way to debug correctly though.
At least, that's what it looks like to me.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
