Created attachment 153147 [details] Test document to show the problem When in a sheet document with more than one sheets rows were inserted in the second or later sheets (not the first sheet!) and filled via Paste the row and cell format attributes are not respected, means e.g. "Wrap text automatically" is not respected and as a consequential error row height is calculated not correctly. After the document was saved, closed and reopened, row and cells are displayed correctly. Steps to reproduce the bug: - open the attached document "Test_Zeilenhöhe_bei_Einfuegen.ods" - go to sheet "Tabelle1" - insert a row above e.g. row 4 - select whole row 3 and copy it to the clipboard - got to cell A4 (first cell in the inserted row) and paste the clipboard content (Ctrl+V) - Result: Content of the cells is inserted, but text in cells C4 and G4 isn't wrapped, although cell format attributes say "Wrap text automatically", and the row height is not changed. - save the document, close and reopen it - Result: Inserted row 4 is displayed correctly. When the same is done on the first sheet the problem doesn't exist. To test one can change the sequence of the sheets, means shift "Tabelle1" on the first position, and then execute the steps described above. The problem doesn't exist in LO 6.3.0 and LOdev 6.3.1.
Hi Stefan, I reproduce with LO 6.4.0.0.alpha0+ (x86) Build ID: 5ba84c3c7080d55d86b8b39db077b6da36cb700a CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; Locale: fr-FR (fr_FR); UI-Language: en-US Calc: CL Date: 2019-07-30 but not with LO 6.4.0.0.alpha0+ (x86) Build ID: 11a1bdc5fa0312111ddf9c1b7779a114b97e361c CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; Locale: fr-FR (fr_FR); UI-Language: en-US Calc: CL Date: 2019-06-19 Jacques
With the information of Comment 1 as base I have checked when the problem occurs first. In my tests I couldn't reproduce the problem with the build Version: 6.4.0.0.alpha0+ (x64) Build ID: 4808ae1c73597726c89936f5b9cb3f11c9a4a7bf CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-25_01:14:33 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded and all earlier builds. The first build I can reproduce the problem with is Version: 6.4.0.0.alpha0+ (x64) Build ID: 9a2fbfa3cc1da8bd9388d5b4c780e86f0dccc791 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-25_23:12:21 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Problem can also be reproduced with all newer builds of LO 6.4.0.0, last tested until now is Version: 6.4.0.0.alpha0+ (x64) Build-ID: b9b7df5f558eb79533622df5f3390f79a1e5aa79 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-07-31_17:15:25 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded I hope this helps to find what change is responsible for the problem.
The problem seems to be resolved without anyone has explicitly worked on. I cannot reproduce the incorrect behavior with Version: 6.4.0.0.alpha0+ (x64) Build-ID: d3d13140f0036c53aa74820b41acfeffa3572168 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-14_12:05:15 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded