2020-09-02 01:51 PM - last edited on 2022-09-26 10:45 PM by Daniel Kassai
some script if condition is met then gosub 001 _tempArray = _origArray !<--both arrays are one dimension endif some script end 001: dim _tempArray return
Solved! Go to Solution.
2020-09-02 03:35 PM
gosub 100 _newVALUE = _tempArray[1] end 100: dim _tempArray[] _tempArray[1] = 2 returnBut if you change this into this, it works:
gosub 100 gosub 200 end 100: dim _tempArray[] _tempArray[1] = 2 return 200: _newVALUE = _tempArray[1] returnThis is a weird thing, but I think, it is a bug.
2020-09-02 03:35 PM
gosub 100 _newVALUE = _tempArray[1] end 100: dim _tempArray[] _tempArray[1] = 2 returnBut if you change this into this, it works:
gosub 100 gosub 200 end 100: dim _tempArray[] _tempArray[1] = 2 return 200: _newVALUE = _tempArray[1] returnThis is a weird thing, but I think, it is a bug.
2020-09-02 06:29 PM
2020-10-06 01:55 PM
2020-10-06 05:07 PM
Joachim wrote:This isn't a bug, it's a limitation. The order of statements can depend on parameters, it is only known at run-time. Variables mustn't change their types during run, the best the interpreter can do is check the code line-by-line (there are simple cases when the order of execution is evident, but it can get complicated very easily). If it didn't do this check, it would be possible to get error messages only by some parameter states, which would make them very hard to detect and understand.
This is a weird thing, but I think, it is a bug.