Bug 104902 - unable to display chr(10) or chr(13) in a cell in calc when inserted by a macro
Summary: unable to display chr(10) or chr(13) in a cell in calc when inserted by a macro
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium minor
Assignee: Andreas Heinisch
URL:
Whiteboard: target:7.4.0 target:7.3.2
Keywords:
Depends on:
Blocks: Macro-UNOAPI
  Show dependency treegraph
 
Reported: 2016-12-24 08:04 UTC by prevotmathieu
Modified: 2022-09-20 15:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample file (11.44 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-12-25 22:31 UTC, m.a.riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description prevotmathieu 2016-12-24 08:04:20 UTC
On any sheet execute this macro:
****
dim document   as object
dim dispatcher as object

rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "ToPoint"
args1(0).Value = "$A$1"

dispatcher.executeDispatch(document, ".uno:GoToCell", "", 0, args1())
dim args2(0) as new com.sun.star.beans.PropertyValue
args2(0).Name = "StringName"
args2(0).Value = "123" & chr(13) & "456"

dispatcher.executeDispatch(document, ".uno:EnterString", "", 0, args2())
****

The A1 cell will display
123456
It should display 
123
456

Interestingly enough, the string is correctly displayed in the formula bar.
Comment 1 m.a.riosv 2016-12-25 22:31:30 UTC
Created attachment 129939 [details]
Sample file

To insert line break libreoffice calc uses chr(10) not chr(13)

https://help.libreoffice.org/Common/Inserting_Line_Breaks_in_Cells
Comment 2 prevotmathieu 2016-12-26 08:58:36 UTC
Yep, I'm aware of the use of chr(10) instead of chr(13),however that doesn't work either.

If you enter 

args2(0).Value = "123" & chr(10) & "456" 

The A1 cell will display
123456
It should display 
123
456

So I reopen the bug and change the title.
Comment 3 m.a.riosv 2016-12-26 21:02:52 UTC
Strange what is happening here.

After run the macro, editing with [F2] make visible the line break but if nothing is changed with the editing before press enter, the visualization issue remains, and saving the file the line break desappears.
But changing something like adding a space at end, makes the line break visible and it's preserver when saving.

That doesn't happend with manual or fomula line break.
Comment 4 QA Administrators 2017-12-27 03:25:13 UTC Comment hidden (obsolete)
Comment 5 prevotmathieu 2017-12-27 09:25:58 UTC
Still present

Version: 5.4.4.2 (x64)
Build ID: 2524958677847fb3bb44820e40380acbe820f960
Threads CPU : 2; OS : Windows 6.19; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: group
Comment 6 Buovjaga 2019-08-11 11:51:13 UTC
(In reply to m.a.riosv from comment #3)
> Strange what is happening here.
> 
> After run the macro, editing with [F2] make visible the line break but if
> nothing is changed with the editing before press enter, the visualization
> issue remains, and saving the file the line break desappears.
> But changing something like adding a space at end, makes the line break
> visible and it's preserver when saving.
> 
> That doesn't happend with manual or fomula line break.

Still repro with file

Arch Linux 64-bit
Version: 6.4.0.0.alpha0+
Build ID: 37fc9f51a8de11d40632e8cda17ccf1fa4b1f503
CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 6 August 2019
Comment 7 himajin100000 2019-09-22 00:38:44 UTC
Just a guess:

probably cell content is displayed as Rich Text, While Formula bar is for normal string.

When Enter Key is manually pressed with Shift key pressed, InsertLineBreak is executed. 

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/editeng.cxx?r=39214c54#1233

this sets special attribute EE_FEATURE_LINEBR

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?r=39214c54#3031

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/editdoc.cxx?r=39214c54#345

and later this will be used to create lines.

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit3.cxx?r=bb748ba4#1025

CreateLines is called from FormatDoc
https://opengrok.libreoffice.org/xref/core/vcl/source/edit/texteng.cxx?r=73e3604f#1514

and FormatDoc is called from TextEngine::ImpPaint
https://opengrok.libreoffice.org/xref/core/vcl/source/edit/texteng.cxx?r=73e3604f#1881
Comment 8 himajin100000 2019-09-22 08:14:48 UTC
Can anyone explain how "GetString converts line breaks into spaces in EditCell"?
I was unable to understand mainly due to lack of my brain ability.

https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/cellform.cxx?r=fce7c123#162
Comment 9 QA Administrators 2021-09-22 03:37:44 UTC Comment hidden (obsolete)
Comment 10 Commit Notification 2022-02-15 06:47:06 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/44d237c375b7ef9a5a61a2f752bd19b57649ffbd

tdf#104902 - Handle embedded newline in Calc's .uno:EnterString

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Andreas Heinisch 2022-02-15 06:49:55 UTC
This may lead to performance issues, but unfortunately I could not reproduce any on my system. I would set it fixed for now, but if there are any performance issues, I would still have an optimization in mind to reduce the row height changes.
Comment 12 Buovjaga 2022-02-15 11:42:47 UTC Comment hidden (obsolete)
Comment 13 Buovjaga 2022-02-15 11:43:26 UTC
(In reply to Andreas Heinisch from comment #11)
> This may lead to performance issues, but unfortunately I could not reproduce
> any on my system. I would set it fixed for now, but if there are any
> performance issues, I would still have an optimization in mind to reduce the
> row height changes.

I created a version that inserts the string 10000 times. Without your patch it finishes in under 2 secs (stopwatch time). With your patch it takes 11 secs.

REM  *****  BASIC  *****

Sub Main
dim document   as object
dim dispatcher as object

rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

dim args2(0) as new com.sun.star.beans.PropertyValue
args2(0).Name = "StringName"
args2(0).Value = "123" & chr(13) & "456"

dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "ToPoint"
for i=1 to 10001
	args1(0).Value = "$A$" & i
	dispatcher.executeDispatch(document, ".uno:GoToCell", "", 0, args1())
	dispatcher.executeDispatch(document, ".uno:EnterString", "", 0, args2())
next i

End Sub
Comment 14 Andreas Heinisch 2022-02-15 14:28:52 UTC
Ya, here we have this problem that even with my optimization in mind (saving all the rows and adjust the height at the end of the process) would not increase the performance.

Is this deacrease in performance acceptable, since we have to check if there is a new line in the according row and adjust the height accordingly.
Comment 15 Buovjaga 2022-02-15 14:33:30 UTC
(In reply to Andreas Heinisch from comment #14)
> Ya, here we have this problem that even with my optimization in mind (saving
> all the rows and adjust the height at the end of the process) would not
> increase the performance.
> 
> Is this deacrease in performance acceptable, since we have to check if there
> is a new line in the according row and adjust the height accordingly.

I guess the correctness is more important. I tried without newline and it took 7.5 secs.
Comment 16 Andreas Heinisch 2022-02-15 14:36:14 UTC
Tecnically, we could remove the AdjustRowHeight, but it would not adjust the correct row height :), albeit the new line survives the reload of the document.
Comment 17 Commit Notification 2022-02-15 20:29:22 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/7f220aeae695e06c5e5dfed6ccf1d8b8f8a13e6e

tdf#104902 - Handle embedded newline in Calc's .uno:EnterString

It will be available in 7.3.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Buovjaga 2022-02-16 09:13:59 UTC
(In reply to Buovjaga from comment #13)
> (In reply to Andreas Heinisch from comment #11)
> > This may lead to performance issues, but unfortunately I could not reproduce
> > any on my system. I would set it fixed for now, but if there are any
> > performance issues, I would still have an optimization in mind to reduce the
> > row height changes.
> 
> I created a version that inserts the string 10000 times. Without your patch
> it finishes in under 2 secs (stopwatch time). With your patch it takes 11
> secs.

After re-testing, looks like I made a mistake here: it takes 7.5 secs without your patch, so probably with your batched row height adjustment idea there will be no perf difference.
Comment 19 Buovjaga 2022-02-16 09:38:38 UTC
(In reply to Buovjaga from comment #18)
> After re-testing, looks like I made a mistake here: it takes 7.5 secs
> without your patch, so probably with your batched row height adjustment idea
> there will be no perf difference.

Was bumbling again: of course it would require changing the Basic script itself to be smarter to get rid of that perf gap.