Another Parser Bug

[Walt Decker]

Unlike a CALLDLL declaration one can not break up an LB SUB/FUNCTION with the underscore character.

Given:

SUB DefType BYREF W, BYREF H, BYREF X, BYREF Y, BYREF Z, BYREF A, _
 B, C

END SUB

The parser will stop at the underscore character with the message ' "_" is not a variable'

[Carl Gundel]

Mar 28, 2022 15:13:27 GMT -5 Walt Decker said:

Unlike a CALLDLL declaration one can not break up an LB SUB/FUNCTION with the underscore character.

Given:

SUB DefType BYREF W, BYREF H, BYREF X, BYREF Y, BYREF Z, BYREF A, _
 B, C

END SUB

The parser will stop at the underscore character with the message ' "_" is not a variable'

Interesting find.

[Dennis]

Hi
I think if you remove the space before the "_" it might work.
Did not try it though, but I recall hitting a similar problem some time ago.
Regards
Dennis

[Walt Decker]

It is even worse. If the module is a FUNCTION instead of a SUB the parser stops with the message "compile halted: syntax error" and highlights the first line of code in the app. That leaves the coder with no idea of where or what the error is.

I have found another bug, but I want to work out exactly how to present it before posting it.

[Brandon Parker]

Mar 29, 2022 9:53:13 GMT -5 Walt Decker said:

It is even worse. If the module is a FUNCTION instead of a SUB the parser stops with the message "compile halted: syntax error" and highlights the first line of code in the app. That leaves the coder with no idea of where or what the error is.

If you try running it again without clicking inside the editor, it will highlight the function header. LB is actually trying to highlight the code the first time since LB asks if you want to run the selected code on the second go-around; selecting "No" will subsequently allow LB to highlight the function.

That might be an LB issue or it could be a scintilla issue; only Carl could find out...


{:0)

Brandon Parker