Created attachment 155970 [details] Sample with labels Given this in A1:C6: > jan feb mar > 1 2 3 > 2 3 4 > 3 4 5 > 4 5 6 > 5 6 7 defining labels in A1:C1 for columns in A2:C6 (Sheets->Named Ranges and Expressions->Labels...) and putting this formula into D2: `='jan'*'feb'*'mar'` the result is correct 6. But drag-copying the formula down into D3:D6 produces the column of 6s, while values must be different for each row (6, 24, 60, 120, 210). Hard recalc doesn't help, but minimal editing of the formula makes it work OK; also if you try to drag the wrong value 6 from, e.g., D3 into D4, the value in D4 would be 60; dragging the 6 from D3 into D4:D5 gives two 24s. But the same works fine when the labels are for rows, not columns. Consider this in A12:F14: > apr 1 2 3 4 5 6 > may 2 3 4 5 6 7 > jun 3 4 5 6 7 8 set labels in A12:A14 for rows B12:F14; and put `='apr'*'may'*'jun'` into B15. The cell then drag-copies fine into C15:F15. See sample file with pre-configured data, where only drag-copy is left. Version: 6.3.3.2 (x64) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
(In reply to Mike Kaganski from comment #0) > the result is correct 6. But drag-copying the formula down into D3:D6 > produces the column of 6s, while values must be different for each row (6, > 24, 60, 120, 210). Hard recalc doesn't help, but minimal editing of the > formula makes it work OK; also if you try to drag the wrong value 6 from, > e.g., D3 into D4, the value in D4 would be 60; dragging the 6 from D3 into > D4:D5 gives two 24s. reproducible with: Version: 6.5.0.0.alpha0+ (x64) Build ID: d04eef858250f97690f32dba17f42d157a8767fc CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded btw: a save & reload will fix it too, even with [Never Calculate] on load enabled
Regression between 4.2.0.4 (works fine) and 4.3.0.4 (problem reproducible).
Created attachment 156003 [details] bibisect-42max, tail of terminal output Contrary to comment 2, bibisect-linux-64-releases on debian-buster shows the bug starting between libreoffice-4.1.6.2 and libreoffice-4.2.0.0.beta1. I wonder what Mike and I did differently. Working in bibisect-42max on debian-buster shows the bug entering LibreOffice: commit s-h date -------- -------- ------------------- good 7d71309c a592b815 2013-08-12 23:46:28 bad 095d00d8 bbb2d8c6 2013-08-12 23:46:29 From git log: commit bbb2d8c660b515c98624a41a39ffe94d3a7ecc00 Author: Kohei Yoshida <kohei.yoshida@gmail.com> Date: Fri Aug 9 16:41:22 2013 -0400 If the formula cell is grouped, update reference only on the top cell. Change-Id: I5e2e9db621a61deba39a46962e0ca877235d7c90 I am removing keyword bibisectRequest and adding bisected, bibisected.
(In reply to Terrence Enger from comment #3) > I wonder what Mike and I did differently. The only likely thing is that I tried on Windows: could it be that some engine (grouping?) had been enabled on Windows later than on Linux? Thank you very much! Kohei, Eike: what do you think, does the patch need reverting (performance regressions?), or is some clever processing needed?
However, ScFormulaCell::UpdateReference doesn't seem to get called when drag-copying; so https://git.libreoffice.org/core/+/bbb2d8c660b515c98624a41a39ffe94d3a7ecc00 doesn't seem like a real problem here. Could the problem be in ScColumn::CloneFormulaCell?
Dear Mike Kaganski, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I'll leave that up to you, Mike (revert or not). I personally don't see value in keeping this label feature since it was a feature copied from Excel but Excel itself dropped long ago (in 2007). This was one feature that never meshed well with the rest of the formula engine code... But that's just my selfish opinion.
Add my selfish opinion to make that 2 ;p Probably the worst feature in spreadsheet world Excel came up with ever.. Anyhow, the indicated commit is not the culprit, I think I know where it goes wrong.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89c4bc5220810dc3684a473f87d001f2c55438a1 Resolves: tdf#128914 Create copies for non-shareable token arrays 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.
Mike was perfectly right with ScColumn::CloneFormulaCell()
Pending review https://gerrit.libreoffice.org/c/core/+/125725 for 7-2
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fabed8f7b9a5e57cbb62e6570349c33f000c2291 tdf#128914: sc_uicalc: 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/2997c5c2604cd5054710ad35e1e0a9fd18f8ae79 Resolves: tdf#128914 Create copies for non-shareable token arrays 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.
7.2.4 was a hotfix release, updating target in status-whiteboard