Description: When inserting a new row from a starbasic macro into a Writer table, the table formatting disappears. Insertion is carried out using the InsertByIndex method. After inserting a row, the entire table loses its font styles and colors. Tested on versions: 7.6.7.2, 7.5.6.2, 24.2.3.2 - there is an error On version 6.x.x.x - it works fine An .odt file that demonstrates this situation is attached. Steps to Reproduce: 1. Open attached file 2. Click the button Actual Results: The fonts and styles of the entire table have disappeared Expected Results: The fonts and styles of the entire table should have remained Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded
Created attachment 194311 [details] File to show bug
Thanks for the report. The same happens if inserting a row with the Table toolbar, which makes it look like bug 126008, a known issue about AutoFormat styles (and might depend on availability of such styles between version of LO). But you are right that the macro method would work without removing formatting back in 6.0.0.3, while the toolbar command would remove it. However, you can still reproduce with the macro by first placing the cursor inside the table before running it. The macro method started failing directly in 6.1. Bibisected with linux-64-6.1 to first bad build [54727c22fdde9ad29e59fabeaa63df9bf9a90909] which is: commit 137c38a1ba01c51c421f695e1558d2c1499c6627 author Jim Raykowski <raykowj@gmail.com> Sat Apr 28 22:20:51 2018 -0800 committer Michael Stahl <Michael.Stahl@cib.de> Mon May 21 22:26:37 2018 +0200 tdf#117189 Fix table InsertRow redo Reviewed-on: https://gerrit.libreoffice.org/53618 See this relevant comment from the bug report: (In reply to Jim Raykowski from bug 117189 comment #7) > [...] > So a new approach to fix this bug is to move the cursor into the table when > restored with redo. This approach can be tested manually by removing this > patch or using a version before this patch was merged. ...which confirms my observation about moving the cursor. Not calling this a regression, as it only made a pre-existing issue visible (Jim can confirm?). *** This bug has been marked as a duplicate of bug 126008 ***
"However, you can still reproduce with the macro by first placing the cursor inside the table before running it." No, this method doesn't work either. You can check it on my attached file.
(In reply to Massaraksh7 from comment #3) > "However, you can still reproduce with the macro by first placing the cursor > inside the table before running it." > > No, this method doesn't work either. You can check it on my attached file. I meant: You can still reproduce _the bug_ in e.g. LO 6.0 by placing the cursor into the table before running the macro.
It is now clear.
They helped me solve the problem on the forumooo.ru forum. It turned out that it is enough to first execute the code: Sub RemoveDefaultTableStyle Dim oTextTables, table oTextTables = ThisComponent.getTextTables() For Each table In oTextTables table.TableTemplateName = "" Next End Sub Then, when inserting rows, the styles do not get corrupted. https://forumooo.ru/index.php?topic=11204.30