| Summary: | Change For loop in non-compatibility to calculate bounds once, OR document the details as they are now | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
| Component: | BASIC | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alain.romedenne, andreas.heinisch, himajin100000, jp, rafael.palma.lima, sokol |
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=150458 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
|
Description
Mike Kaganski
2022-08-17 15:01:54 UTC
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. |