Description: Deleting a row makes references become #REF! and after reinserting the deleted row, #REF! cell recovers the last value and fórmula, however it's never updated anymore. Steps to Reproduce: 1.In cell A2 put "=A1" 2.Select Row 1 and delete row (A2 will go to A1 and will become "=A#REF!") 3.Select Row 1 and insert row (A2 will become "=A1") however. 4.Insert a value to A1 cell (like "1"). Actual Results: A2 cell doesn't update it's value to "1", even when it's pointing to A1 that contains the value "1" Expected Results: A2 cell should get value "1" Reproducible: Always User Profile Reset: Yes Additional Info: I've tried with Version 6.4.2.2 and the new 7.0.0.0.alpha1
Please try with Menu/Data/Calculate/Recalculate Hard.
Indeed, when I press "Recalculate Hard" it's updated, however you have to press it every time you change A1 value, because it's not Auto-updated on change. And BTW, I have the Autocalculate "on"; And also all the other cells are Auto-updated correctly. The only Auto-update problem is on the "old" #REF! cells.
Yes it does work when you try to recalculate hard the shortcut for this is Ctrl+ Shift + F9 for windows.
repro with below ver. likely a dup of or related to tdf#131339 and / or tdf#128975, Version: 7.1.0.0.alpha0+ (x64) Build ID: 75e1cf6c6ea83e65da248dab917b06feea6c18e4 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
affects linux too, up to ver. 4.1.6.2 different behaviour, #REF error kept after re-insert of row, next tested ver. is 5.0.0.1 - buggy as of now, re-insert: decoupled from autocalculate, all ver: undo: correct behaviour, assume break between 4.1 and 4.2 - implementation of shared formulae ... hard recalc <ctrl-shift-F9> is a tool to check for fails of the program, not! a functionality for daily use, if your car won't start, sometimes a hammer tap on the starter helps, that's somehow a 'fix', but you are warned that theere is a problem by the fact that it doesn't move as expected, spreadsheets are different, if you have miscalculations you firstly need to realize that this is the case! ... sometimes you are lucky and see it, in all other cases i recommend a recalculation with pencil and paper ... thus either you see a mistake, or you calculate with pencil and paper ... or you routinely press ctrl-shift-F9 and forget that in the critical moment of the most important sheet of your life ... this is kind of like playing the lottery, please stop recommending such things as fixes ...
add. info: references to cells below affected as well (B2: '=B3'), also 'somewhere in the sheet' (not restricted to borders), also with some distance between reference and referencier (D4: '=D7', but does not affect references to cells besides (B2: '=C2'), reference is 'dead' while input number or text into the referenced cell, but becomes live again on input of formula, e.g. '=3' in the referenced cell will be respected by the referencing cell, at least with below ver. - but from memory it was on other versions too - the cell doesn't 'cell recovers the last value and fórmula', but recovers the last formula, and a fresh calculated '0', Version: 7.1.0.0.alpha0+ Build ID: 20ba8d8d9f4fcf7d5826fcb3366a9bff0d6a8ca1 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-06-10_07:16:41 Calc: threaded
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 26d23c96d449c201e50df04023d9cbfd59d3d133 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This issue never worked before https://cgit.freedesktop.org/libreoffice/core/commit/?id=f32df2d590d0ee14f09664934457ba9e8de8cbe6 < bug 75053 >. Before the mentioning commit, A2 becomes =A#REF! after deleting Row 1 and inserting a new row. @Luboš Luňák, I thought you might be interested in this issue
Dear Daniel, 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