Description: I will refer to the parameters of MULTIPLE.OPERATIONS as defined in ODF v1.2. MULTIPLE.OPERATIONS( Reference FormulaCell Reference RowCell ; variable to be replaced, FormulaCell depends on it Reference RowReplacement ; new value for row Reference ColumnCell ; variable to be replaced, FormulaCell depends on it Reference ColumnReplacement ; new value for col ) If having a chained MULT.OP, where the "FormulaCell" is referencing a cell doing the actual calculation (depending on "RowCell" and/or "ColumnCell"), one can observe, that the "FormulaCell" shows the result of one of the last MULT.OP replacement runs, instead of the result calculated from the default content of "RowCell" and "ColumnCell". The "RowCell" and "ColumnCell" keep their values, as expected. Steps to Reproduce: Check the attachment. 1. Set up a calculation/formula in cell "F" depending on at least 3 variables: f(A,B,C,D). 2. Reference to "F" from another cell "R" 3. calculate MULT.OP(R, A, newA, B, newB), let's call the cell "M" 4. calculate a chained MULT.OP(M, C, newC, D, newD) 5. update/recalculate with F9 and STRG + ALT + F9 Actual Results: The cells "F" and "R" will show f(newA,newB,C,D). Expected Results: The cells "F" and "R" should always show f(A,B,C,D). Reproducible: Always User Profile Reset: No Additional Info: Further cells referencing "F" or "R" will show f(A,B,C,D), which is actually the correct value, but wrong in the sense that "F" and "R" show f(newA,newB,C,D). Version: 6.4.2.2 (x64) Build-ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU-Threads: 2; BS: Windows 10.0 Build 18362; UI-Render: Standard; VCL: win; Gebietsschema: en-GB (de_DE); UI-Sprache: de-DE Calc:
Created attachment 159106 [details] small example showing the bug
I think this report is too abstract for our regular QA to confirm. The example file helps, but I think it could still be more minimal. I never used this function, but from what I see in the example file, you are replacing the contents of cells with contents of other cells. You seem to be layering the replacements on top of each other. Now what is the actual problematic step, I have no idea after reading your explanation and looking at the file. The only concrete thing I see is a note 'should always show "ABCD"' referring to B7 which shows the string HFCD. Ok, I get it, the display is not what you want. I just don't understand how were got there and what is the step that breaks it.
Reproduced on: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: b2130ad3fda841c68a0436fbddf29bcedede0af5 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-08-09_13:03:07 Calc: threaded and: Version: 7.2.0.1 / LibreOffice Community Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I can see the weird behaviour of reference cells having their display value changed. For reference, the function's documentation can be found here: https://wiki.documentfoundation.org/Documentation/Calc_Functions/MULTIPLE.OPERATIONS
Created attachment 174275 [details] other example spreadsheet with steps to reproduce I reproduced by creating this spreadsheet from scratch. This can be another, possibly clearer, example for others to reproduce. The steps are in the spreadsheet.
Created attachment 174276 [details] screenshot of erroneous displayed values in LO 7.3 alpha0+ For completeness' sake, here is a screenshot if what I see in the spreadsheet I attached. The two erroneous displayed values are framed in red.
Dear xyhausen, 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