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.
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
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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
(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
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
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
Dear prevotmathieu, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
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.
(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 1001 args1(0).Value = "$A$" & i dispatcher.executeDispatch(document, ".uno:GoToCell", "", 0, args1()) dispatcher.executeDispatch(document, ".uno:EnterString", "", 0, args2()) next i End Sub
(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
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.
(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.
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.
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.
(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.
(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.