Difference between Step over and Run

[Jim Hurley]

>
>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