Odd behaviour with the debugger today -- initially thought it might be a
bug in v17R3, but then went back to v14 and found the same behaviour....
With the following code:
Trace
For ($Loop1;1;10)
ALERT("Iteration: "+String($Loop1))
For ($Loop2;1;10)
BEEP
End for // <- Put a break point on this line
End for
If you put a break point on line 6 (the first End for), step through
the code in the debugger and go through the second loop a couple of
times, then drag the yellow current line marker OVER the first end for,
when the interpreter steps into the final 'End for', instead of jumping
back to the second line (For ($Loop1;1;1000)) it actually jumps back to
line four!! That wasn't expected.
Guess the situation is that we've never had to debug tightly focused
nested For loops previously and had not noticed this behaviour before.
Presumably once the interpreted is stepped into the final 'End For'
after have skipped the first End For, it's working backwards up the
lines of code to find the first 'For loop to continue running.
Maybe this note will help someone else to avoid wasting time like we
just did trying to work out why 4D is doing what it's doing in this
situation.
Cheers,
Allan Udy
Golden Micro Solutions Ltd, Blenheim, New Zealand
http://www.golden.co.nz<http://www.golden.co.nz>
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
