For Loop

rofl

Hello,

I have a pretty easy problem, but it is not easy to understand. The problem is with for loop.
Basically the whole syntax, let's say, is FOR i := top DOWNTO bottom;
The question is: how that condition (counting) is treated, to be more precise, let say I have top := 10, and bottom := 2. That is clear - it will goes from 10 to 2. But what if I change the bottom value to lets say 12 (inside the loop). Is "bottom" value still 2 and everything in loop remains FOR top DOWNTO 2? Or is it now FOR top DOWNTO 12 (which would stop the loop, but in my case it doesn't stop it, that's why I am asking for this. I think it keeps only primary expression).

Thanks for patience.

Belias

yes, original value!

matttrax

Based on experience with other programming languages I would disagree with Belias.

A FOR loop can be though of as

WHILE TRUE DO BEGIN
IF CounterVariable does not meet some condition THEN
EXIT the while loop;

//Some code, may change the exit condition
END;

C/AL is weird, though. So try it out.

Belias

hi mattrax, i saw a post some time ago and someone said:

"i have to disagree your disagreement"

anyway, c/al keeps the original value as reference, just try this code
all variables ar integer

top := 10;
bottom := 2
for i := top downto bottom do begin
  bottom := 12;
  counting += 1;
  message(format(counting));
end;

don't be afraid, the loop won't be endless, you'll reach only the ninth message...somewhat weird, indeed :-k

rofl

Yep, C/AL is weird thing. Anyway thanks for replies. You confirmed my doubts, hehe.

David_Singleton

Actually the correct answer is "not sure".

This was discussed my Michael Nielsen at Directions a couple of years back. Basically he warned us that if something is not documented we should be careful how we use it since it could change from version to version. Basically you should not change the counters in a for next loop, because the results will be unpredictable.

He showed some good code examples where the numbers coming out did seem quite random. So don;t expect to break the rules and for things to constantly work, one day they wont.

I had a developer once write code something bizare like TimeA /= TimeB; (this was before the +=, -=, *= and /= commands were documented) which logically should not work, since the result (Time/Time -> Integer) means you are populating a time variable with an integer. For some bizzare reason it compiled, but the client was on a different version of executables, and when they imported the object, all sorts of stuff started falling apart, including managing to populate fields in tables with invalid data.

Point is that you may get this working, and then on the next version of NAV is will just give an error, or worse it will process but give the wrong result.

kine

Yes, ad David described. Changing the counting variable or limit variable within the loop can lead to unpredictable results. It means, that it could work, but you cannot be sure. This is same for all languages. Same like changing field value on which you are filtering and so one...