Difference between Step over and Run

J. Landman Gay jacque at hyperactivesw.com
Tue Nov 22 16:43:44 EST 2005


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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



More information about the use-livecode mailing list