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:

For ($Loop1;1;10)
    ALERT("Iteration: "+String($Loop1))
    For ($Loop2;1;10)
    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.

Allan Udy

Golden Micro Solutions Ltd, Blenheim, New Zealand

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

Reply via email to