Apache OpenOffice (AOO) Bugzilla – Issue 59790
Regression in Basic : syntax error with line continuation character
Last modified: 2010-11-10 15:45:12 UTC
Found on build 8990 There are compilation errors related with the Basic line continuation character : _ It could be a consequence of fixing IZ 45570 Sub Main ' comment ending with _ End Sub This provides syntax error: Statement block still open: End Sub missing. Explanation: the line after the comment is not interpreted. Confirmation with this example: Sub Main rem _ a<*+b End Sub The line after the rem should display a syntax error, but it is ignored. This bug is catastrophic because already existing and perfectly working macros may not be usable with 2.0.1. The designer of new macros can stumble on not-understandable messages, because there is no fault.
confirmed.
*** Issue 59801 has been marked as a duplicate of this issue. ***
andreas, this does look like it is related to 45570
This is not related to 45570 but to the SO internal issue 124674 "Concat with "_" doesn't work inside comments" I have to give a few comments here: - This is no regression in the sense that we now have a wrong behaviour while we had a correct behaviour before. The _new_ behaviour is correct as the target is to be compatible with VB. - So the task is "only" that we lost some backward compatibility to old macros. In general that's bad enough, but in this special case I can't see it as "catastrophic" as I doubt that there are many macros contai- ning " _" at the end of a comment. This doesn't make any sense as long as the comment is _not_ extended to the next line then, so why should many programmers write such strange comments? So please have a look at the priority rules at: http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority This is never ever a P1, not even a P2 as I strongly doubt that this problem meets the criteria "P2 marks severe problems which affect a _significant_ number of customers". This is no crash, no data loss. Most users - even if using macros - will not even realise it. I will nevertheless fix this for 2.0.2 by restoring the old behaviour for option compatible not set, but I don't like such exaggerated use of high priorities. -> P3, STARTED
What you mean, and this is not obvious for a non-VB programmer, is that the _ character is now used to continue the comment on the next line. But: - this should be properly documented in the on-line help (and in StarOffice 8 Programmer's Guide) - the syntax coloring in the IDE should "know" this new feature : today it still colors reserved words in the subsequent comment line. About the consequences of the current design, a macro with an ending _ in a comment may work incorrectly, or not at all, because the next line will not be executed. You cannot say "there is no crash, no data loss", anything can happen, with any consequence.
> - this should be properly documented in the on-line help (and in StarOffice 8 > Programmer's Guide) But it is documented. In the current (m150) online help I found under "The Basic Editor" - ok, maybe this is not the most adaquate place: Long lines can be split into several parts by inserting an underline character _ as the last character of a line. This connects the line with the following line to one logical line. - the syntax coloring in the IDE should "know" this new feature : today it still colors reserved words in the subsequent comment line. Right, this indeed is a bug. But as it is surpisingly difficult to fix and I don't consider the whole "REM _" scenario as particularly important, I doubt that it has a chance to be fixed very soon. There are simply too many more important tasks. > About the consequences of the current design, a macro with an ending _ in a comment may > work incorrectly, or not at all, because the next line will not be executed. You > cannot say "there is no crash, no data loss", anything can happen, with any > consequence. The only problem I see is that the behaviour changed. But the old be- haviour just was wrong taking VB as reference. This problem will be solved with my fix. It's correct, that the next line will not be exe- cuted with the new behaviour, but this should be no problem as nobody needs to use " _" at the end of a comment line and if he does, al- though the next line should be executed, it's just a bug in the macro. Still I think this problem really shouldn't be overrated. I deal with OOo Basic / Star Basic for nearly ten years now and before fixing the internal issue 124674 for 2.0.1, I've never seen one single macro with a comment ending on " _". And that's no surprise for me, as the benefit seems to be extremely limited. It's much clearer to also comment the next line instead of extending the comment from the previous line.
Fixed
To check the fix, this example can be used. As long as Option Compatible is commented out, the print command will be executed. ' Option Compatible Sub Main ' This is a comment extendet to the next line _ print "Hello!" End Sub re-open issue and reassign to jsk@openoffice.org
reassign to jsk@openoffice.org
reset resolution to FIXED
OK, this is fixed in that way that it fits to ab's description. However, we could be a little more clear about this in the Help. Submitted issue #61418 for documentation Verified.
Verified on MWS, testing "option compatible" as well. Closing
Created attachment 72992