Bug 150458 describes how VBA treats its bounds (calculating them once at start, allowing to change the variables in the loop without affecting the loop count). This bug is (1) to decide how to proceed in non-VBA modes (Option Compatible, and without the option), and (2) to implement the chosen decision (it should be made "Documentation" if so decided). My personal opinion is that at least for non-compatibility mode, we should not change current behavior, and should document it. But I have no opinion on what to do with Option Compatible mode (should it follow VBA, or our mode)?
Now the situation is not clear. Macro from tdf#150458: Sub test1 Dim i As Long, j As Long, k As Long k=10 For i=1 To k k=1 j=i Next i Msgbox j End Sub shows 1. If you write like this: ... For i=1 To k+0 ... then it shows 10.
If we were designing a new system, I would undoubtedly opt for a single computation of the To and Step expressions before the first loop, like in VBA. The actual behaviour however is, in summary: - there is no difference whatever the Option statement (Compatible, VBA, no option). - when the To or Step clauses are a variable, the clauses are reevaluated at each loop (in fact, it is probably *as if* they were reevaluated) - when the To or Step clauses are an expression, the clauses are not reevaluated (BTW I tested the Step clause too). This duality is IMO the real bug. Nevertheless I don't see how I could support a change in the code in this matter because of the risk on a gigantic legacy (even StarBasic books should be reviewed ...?). Let's promote in the documentation to not depend on the implementation. The only good practice is to never redefine in the loop the variables used in the For statement.
I'm not sure I'm doing something wrong here, but I'm getting 1 as result with AND without "Option VBASupport 1" Sub test Dim i As Long, j As Long, k As Long k=10 For i=1 To k k=1 j=i Next i Msgbox j End Sub The code above is the example from bug 150458. If both behave the same, we should keep as is and simply explain that it is possible to change the upper bound of the loop.
(In reply to Rafael Lima from comment #3) > I'm getting 1 as result > with AND without "Option VBASupport 1" Indeed. And in case of VBASupport, that *must* be changed, because that mode is created exactly to allow running VBA macros as they run in MS Office. > If both behave the same, we should keep as is and simply explain that it is > possible to change the upper bound of the loop. While that would be a possible solution for this issue, it's definitely not for bug 150458.