Description: Calc fails to recalculate dependent cells (see steps to reproduce below). Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded Steps to Reproduce: 1. Open bug 3 (attached) 2. Delete contents of g.X6 (note g.X16 remains =16, which is incorrect) 3. Select c.W281 (it equals 35, which is incorrect) 4. Press F9 (nothing happens) 5. Press F9 again c.W281 changes to 34 (which is correct) I attach the spreadsheet bug 3 (also the macro code which is not executed in the steps above but which you might need). 6. g.X16=13 (which is correct). Actual Results: See above Expected Results: See above Reproducible: Always User Profile Reset: Yes Additional Info: This appeared only when I upgraded to 6.2. I had a similar problem about five years ago (I've looked for and can't find the bug report). Both the current and old problem seemed to occur with the very complex spreadsheet attached. I ran it in safe mode, the same bug appeared except that only one, not two, presses of F9 were needed to perform the recalculation.
Created attachment 148854 [details] Spreadsheet showing bug 123120
Created attachment 148855 [details] Macro code for spreadsheet
Works for me. But macro fails on load. Deleting X6 changes x16. Version: 6.2.1.0.0+ (x64) Build ID: dfa1f1f872c418e89757a3985979b79e94c12fcc CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: threaded
Can you suggest what is wrong, please? As well as rebooting may main computer, I have now tried it on a different computer (Windows 10, same LO version) and I still get the same behaviour.
I don't have a crystal ball. - Test with the macro disable. - Test with a clean profile. - Test with/without OpenCL. - Test with/without multi-threaded calculation.
Dear David Lynch, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
My (only) spreadsheet to spreadsheet to exhibit this problem was very complicated. I have now rewritten it to simplify it, saving 800k. It no longer exhibits the bug. I suspect that it was a circular dependency that LO was not detecting that caused the behaviour. I suggest that the bug is closed.
(In reply to David Lynch from comment #7) > My (only) spreadsheet to spreadsheet to exhibit this problem was very > complicated. I have now rewritten it to simplify it, saving 800k. It no > longer exhibits the bug. > > I suspect that it was a circular dependency that LO was not detecting that > caused the behaviour. I suggest that the bug is closed. Ok, Let's close this issue then.
bug may be kept closed, sheet is too complicated, just to check reliability of calc for the 'bug hunting session', and to save others some time if they attempt an recheck ... (solution at the end) with ver: Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL > 1. Open bug 3 (attached) ok > 2. Delete contents of g.X6 (note g.X16 remains =16, which is incorrect) g.X16 changes to blank, empty or similar > 3. Select c.W281 (it equals 35, which is incorrect) c.W281 now shows -1, i can't find why it should calculate to other value, > 4. Press F9 (nothing happens) running ants, but no change in C.W281 > 5. Press F9 again c.W281 changes to 34 (which is correct) running ants, but no change in C.W281, also on third, fourth and so on press of F9, but changes in g.row6, some 'd' changed to 'a' > I attach the spreadsheet bug 3 (also the macro code which is not executed in the steps above but which you might need). implemented and error message on file open and close gone, thus correct? > 6. g.X16=13 (which is correct). g.X16 still blank, empty or similar on hard recalc - strg-shift-F9 - a long process is started and at the end g.I6:g.X6 are empty .. things which might affect the results: i'd put the macro code in a module of the file, had to re-bind AddListener and RmvListener from that position to open and close event, not checked if other macros are neccessary for recalc ... ************ maybe your script is a little bit inaccurate and and step 2. was intended as: 2. Delete contents of g.*W*6 - you placed the cursor there ... !W6!, not! X6??? then g.W16 changes to empty, and g.X16 to 13, and c.W281 to 34 ... just as you requested ... just after deleting g.W6 ... ************ same with ver 6.2.8.2, thus one can say actual versions are ok for your needs ... <<< one bug killed! >>>