Issue 59790

Summary: Regression in Basic : syntax error with line continuation character
Product: General Reporter: bmarcelly <marcelly.bernard>
Component: scriptingAssignee: joerg.skottke
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P3 CC: issues, pavel
Version: OOo 2.0.1   
Target Milestone: OOo 2.0.2   
Hardware: All   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description bmarcelly 2005-12-26 08:53:37 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.
Comment 1 pavel 2005-12-26 20:03:37 UTC
confirmed.
Comment 2 pavel 2005-12-27 08:39:19 UTC
*** Issue 59801 has been marked as a duplicate of this issue. ***
Comment 3 noel.power 2006-01-16 10:33:26 UTC
andreas, this does look like it is related to 45570
Comment 4 ab 2006-01-18 11:56:07 UTC
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
Comment 5 bmarcelly 2006-01-18 13:06:13 UTC
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.
Comment 6 ab 2006-01-18 13:59:33 UTC
> - 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.
Comment 7 ab 2006-01-25 10:12:04 UTC
Fixed
Comment 8 ab 2006-01-27 14:13:51 UTC
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
Comment 9 ab 2006-01-27 14:13:55 UTC
reassign to jsk@openoffice.org
Comment 10 ab 2006-01-27 14:14:00 UTC
reset resolution to FIXED
Comment 11 joerg.skottke 2006-01-31 11:28:37 UTC
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.
Comment 12 joerg.skottke 2006-02-21 12:32:28 UTC
Verified on MWS, testing "option compatible" as well. Closing
Comment 13 siapenzulu 2010-11-10 15:45:12 UTC
Created attachment 72992