Description: A macro has been developed to ease duplicating a row at end of the worksheet, which is marked by a yellow line (full row in yellow) :- Row X: End of Worksheet, Row X+1: Yellow Line. After upgrading to 7.2, a new row is correctly inserted between Row X and Row X+1. However, instead of duplicating data to the new row, where it used to do in the past, LibreOffice is pasting data to Row X, leaving the newly added row blank :- Row X: End of Worksheet, overwritten, Row X+1: new row, blank Row X+2: Yellow Line. Steps to Reproduce: 1. I guess somebody can look into related macro environment, see if any changes have been brought into scene with 7.2 upgrade. 2. 3. Actual Results: n/a Expected Results: n/a Reproducible: Always User Profile Reset: No Additional Info: It is something serious, because it is hitting all files created prior to version 7.2.
I am obliged to remain on 7.1.5.2.
Not correct and clear bug report. You need to write reproducible steps, what's Experienced and Expected. Here you also need to attach sample ODS with some data and macro, with steps that are exactly described for those data.
Sorry that it is felt insufficient data has been provided. What's Experienced and Expected: I believe such has been described. It is true that no reproducible steps have been provided, and in this situation only a sample file will illustrate the point. The file is not provided because, as I see the situation: macro behavior only changes when transiting from ver 7.1.5.2 ver 7.2.0.4, and this is clear enough a general issue with ver 7.2.0.4 - same macro working in older versions but not the new one, implying a very high possibility of something happening with the new version application. I therefore think that the first step is to verify if indeed there are changes introduced ending in affecting macro behaviour, whether intentional or unintentional. For example in a previous version change, the use of "#" in hyperlink is amended (or rectified), thus once said everybody knows why the new behaviour of hyperlinks in the then new version LibreOffice (ENDCODEURL needed as a fix). If at this point the situation cannot be followed up, just let it be, and be aware of a potential issue with macros, as chance is there that other issues will surface, affecting some other users.
[Automated Action] NeedInfo-To-Unconfirmed
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 174878 [details] Sample Worksheet The attachment is a sample file, which is still working fine prior to LibreOffice 7.2. It begins behaving out of order using the version 7.2 system. Note 1. The three buttons on the top left are respectively for sorting, add a new row, and duplicate a row (duplicating the row where the cursor is, when it is below the second and above the last row, ie. in the main data area). 2. The second row is for defining the sort order; simply using 1, 2, 3 to define the sequence, using -1, -2, -3 to take descending order. PS The buttons were previously genuine buttons, but on a LibreOffice upgrade earlier on, the buttons failed (causing the macros to work incorrectly), while the macros remained working absolutely correctly by themselves, therefore the switch to using shapes instead. This was a pretty long time ago.
Linux 7.2 commit 7eec0829d44ff995d0f7d240a27819fec29624bf Date: Fri Apr 30 21:50:27 2021 +0200 source 61386aa03cd166473a58dbb4be0dd5e0ce82195c pre deac5c84732c3491a0ef5bf7f8c1552e6def4fc0 Not sure if this old OO macro is correct so not confirming as a regression.
I wish to reiterate that the macro though old has been working fine up to version 7.1; if the said macro is not correct, it should not have been running in the first place. As said, it only turns bad from version 7.2, implying something done, whether intentionally or unintentionally in the new platform. If there is the change and nobody knows about it, then an unintentional change, it can potentially cause trouble sooner or later. In case this is something intentional, backward compatibility has obviously been missed. The present situation is creating an version barrier, implying that people wishing to maintain the present workability of the stuffs will have to stay on version 7.1, and cannot go any further. This may be of some thoughts to the developer.
(In reply to Timur from comment #7) > Linux 7.2 commit 7eec0829d44ff995d0f7d240a27819fec29624bf > Date: Fri Apr 30 21:50:27 2021 +0200 > source 61386aa03cd166473a58dbb4be0dd5e0ce82195c > pre deac5c84732c3491a0ef5bf7f8c1552e6def4fc0 > > Not sure if this old OO macro is correct so not confirming as a regression. This is https://git.libreoffice.org/core/+/61386aa03cd166473a58dbb4be0dd5e0ce82195c%5E! ...which is short and doesn't look directly related to macros. Anyone interested may first try reverting this patch to confirm the bibisection result.
(In reply to Ming Hua from comment #9) > This is > https://git.libreoffice.org/core/+/61386aa03cd166473a58dbb4be0dd5e0ce82195c%5E! Bugzilla doesn't handle URLs with exclamation marks well, so use this instead: https://git.libreoffice.org/core/+/61386aa03cd166473a58dbb4be0dd5e0ce82195c
Change was in bug 79049 as a speedup. It caused this bug and bug 144085. Question is what is more important and if this macro can be created differently.
(In reply to Timur from comment #11) > Question is what is more important and if this macro can be created > differently. Heh, no. In this specific case, there is no questions. This change broke a *published API*. Specifically, XUsedAreaCursor Interface is documented [1] to operate on "used area of the entire sheet", which is "the smallest cell range that contains all cells of the spreadsheet with any contents (values, text, formulas) or *visible formatting (borders and background color)*". Breaking published API is no-go :-) [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1sheet_1_1XUsedAreaCursor.html
> Assignee: CSLam @CSLam: have you assigned the issue to yourself because you intend to work and resolve it? Or have you done that by a mistake, and doing so, prevent others from taking it and actually resolving?
Thank you for pointing out the assignee issue, Mike. It definitely is by mistake that I assigned the fault to myself. If I can handle it myself, this would not have appeared here.
Hi Noel. Please see this as a result of you commit.
fixed with https://cgit.freedesktop.org/libreoffice/core/commit/?id=d8b765e6c45792bff5717cd0e0d9d42311c33461
Closing as duplicated of bug 144085 *** This bug has been marked as a duplicate of bug 144085 ***