Description: - Basic macro - String with embedded newline by ..." + Chr(10) + "... - setting the string into a cell with range.SetString() causes the cell to display the string and its newline - setting the string into a cell with range.SetDataArray() causes the cell to display the string but suppress the newline - editing the bad cell by select, F2, [enter] does not change the display - editing the bad cell be select, F2, _any change whatsoever_, [enter] causes the cell to display the newline correctly Test case attached Steps to Reproduce: See attached test sheet and its macro that demonstrates the issue Actual Results: Display does not show string with its newline, it's all squashed up Expected Results: Display shows string with its newline so it looks nice Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Discovered on 6.0.7.3, upgraded to 7.1.2.2, still present. There is a dialog box that proves the newline is still in the string, it is a display bug only. Still, it needs to be fixed because data is not presented as intended. Ubuntu 18.04 x64 stuart@home:~$ glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: AMD TAHITI (DRM 2.50.0, 5.4.0-72-generic, LLVM 10.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.0.8 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 20.0.8 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
Created attachment 171575 [details] Minimal reproduction test case Ensure macro security settings allow running macros. Open the macro editor, then run the macro.
Range.SetDataArray() with a TypeClass_STRING element creates a plain text cell (with an embedded LF character here), whereas Range.SetString() (and editing a plain text cell with embedded LF) creates an EditText object cell for that case. Only text objects are evaluated for display whether they contain multiple lines (or any rich text formatting), hence the difference. We could do the same check as in SetString() whether to create plain text or edit text also in SetDataArray().
This calls for an EasyHack. Code pointers: In sc/source/ui/unoobj/cellsuno.cxx lcl_PutDataArray() for case uno::TypeClass_STRING check for multiline string like in ScDocFunc::SetStringOrEditCell() of sc/source/ui/docshell/docfunc.cxx It may look appealing to use the very same function, but the called SetEditCell() and SetStringCell() have way too much (duplicated) overhead for the array case, which is handled separately here. However, for the resulting edit cell case the row height treatment likely will have to be similar as in ScDocFunc::SetEditCell(), but not executed immediately but just after processing the array for only the affected rows.
1. Create a new book and execute the macro: Sub Test ThisComponent.Sheets(0).getCellRangeByName("A1").setDataArray Array(Array("A" & Chr(10) & "B")) End Sub 2. Save the book, close it and reopen it. The value of cell A1 is now "AB". In my opinion, changing the value of a cell is a critical error.
Such embedded linefeed in a office:value-type="string" cell is saved as <text:p>A<text:line-break/>B</text:p> and the linefeed is not read back in as an embedded linefeed again. Whereas a rich cell text (entered with A Ctrl+Enter B) is saved as two paragraphs <text:p>A</text:p> <text:p>B</text:p> and properly read back in. Not handling <text:line-break/> is a bug, but would be a different one. Care to create one?
I can create a new bug, however, I cannot reproduce the problem situation in a different way than in # 4. Create?
@Andreas, I thought you might be interested in this issue
(In reply to Vladimir Sokolinskiy from comment #6) > I can create a new bug, however, I cannot reproduce the problem situation in > a different way than in # 4. Create? I'd guess so, because according to ODF <text:p>A<text:line-break/>B</text:p> would be valid content, even if with a fix of the problem here it wouldn't be written anymore from this scenario. See 6.1.5 <text:line-break> https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1415206_253892949
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b9e2c5d2a36fbd189c20448cadf4212edf02914d tdf#142033 - Handle embedded newline set via SetDataArray It will be available in 7.3.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.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/bc412136e4325b9b615afdd864c61488fd1ffdcc tdf#142033 - Handle embedded newline set via SetDataArray It will be available in 7.2.4. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cf41b69356672dcedc4448661547c10dbe03f98a tdf#142033: sc_macros_test: Add unittest It will be available in 7.3.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.
7.2.4 was a hotfix release, updating target in status-whiteboard
Confirmed fixed in 7.3.2.2. Thanks!