Difference between Step over and Run

[Jim Hurley]

>I have noticed in the debugger that there is quite a difference in
>time of execution between
>
>     Step over
>
>and
>
>     Run
>
>even when Run takes me to the very next line of code--a line which is
>also a break point.
>
>When the handler to be Stepped over is complex, the time to execute
>Step over can be prohibitive. In such cases I set a break point at
>the next line and Run to the next line. This is VERY much faster.
>
>Is this a bug? Wouldn't it be better if RR executed Step over as if
>it were a Run to the next line of code? Does the "Step over" do
>something other than "Run" to the next line when that next line is a
>breakpoint?
>
>Jim
>


I knew it would come to this some day. Here I am responding to my own 
message. (I don't own a cell phone, but I appreciate them 
nevertheless. I can hold my hand to my ear and talk to my imaginary 
friends without attracting undue attention.)

Here is an example of the problem I have with the debugger. The 
following handlers are in a button script:

on mouseUp
   lock screen
   doWindowWork--There is a break point marker at this line.
   beep--There is also a break point marker at this line.
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



When I run MouseUp and Step over the line "doWindowWord" in the 
debugger, it take 1100 ticks to get to the next line, "beep"

When I hit "Run" at dowindowWork it takes 10 ticks to run to the next 
line, "beep"

Now it gets really weird. If you comment out the "lock screen" line 
it takes only  30 ticks to step over the doWindowWork line. The 
doWindowWork is 30 fold faster if the screen is not locked. (This 
applies only to scripts run in the degugger.)

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.

You  can try  your luck at:

In the message box:

     go stack url "http://home.infostations.net/jhurley/WeirdDebugger.rev"

(Be sure to set break point markers at the indicated lines.)


Jim