Description: In Calc, Options/Calc>Calculate set to automatically find labels Open LabelBad.ods. Cell B3 (='aa'+2) shows error. insert row above ‘aa’; error remains, even after editing. Enter string, eg ‘**’ in cell A1; error remains; edit formula: error vanishes! Strange. Apparently, there must be something above ‘aa’ to make it useable. Open LabelBaf.ods. Cell B3 (='Rz'+1) shows wrong value, 1 instead of 3. (Who can trust Calc if it gives wrong values without warning?) Now, enter label ‘cc’ in cell A3. Cell B3 shows error! Enter ‘**’ in cell A1; error remains; edit formula: error vanishes! Steps to Reproduce: 1.Open LabelBad.ods. 2.Open LabelBaf.ods. 3. Actual Results: 1. Cell B3 shows error. 2. Cell B3 shows wrong value Expected Results: correct values! Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.4.1 (x64) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL
Created attachment 177501 [details] file with formula
Created attachment 177502 [details] file with formula
Automatically finding labels prioritizes on column labels if the next cell above/below the found label cell does not have text content at the moment the cell formula is compiled (not interpreted). What happens here is that in both documents the intersection of the label in 1.A1/2.A2 and the formula cell in B3 is A3 instead of the expected 1.B1/2.B2. If a numeric value is entered in A3 in either document it can be observed. Automatic labels are fragile (and should be deprecated in the UI option settings). Best use defined label ranges, Sheet -> Named Ranges and Expressions -> Labels...
(In reply to Eike Rathke from comment #3) > Automatically finding labels prioritizes on column labels if the next cell > above/below the found label cell does not have text content at the moment > the cell formula is compiled (not interpreted). What happens here is that in > both documents the intersection of the label in 1.A1/2.A2 and the formula > cell in B3 is A3 instead of the expected 1.B1/2.B2. If a numeric value is > entered in A3 in either document it can be observed. > > Automatic labels are fragile … but VERY convenient! and should be deprecated in the UI option settings Why? The bug (as explained above) should be easy to fix Best use defined label ranges, > Sheet -> Named Ranges and Expressions -> Labels... Yes, but they are clumsy
(In reply to TorrAB from comment #4) > (In reply to Eike Rathke from comment #3) > > Automatic labels are fragile > > … but VERY convenient! But not necessarily deterministic and persistent. > > and should be deprecated in the UI option settings > Why? Because their detection depends on data content and arrangement. If later a cell content is added with the same string that is nearer to the formula cell then a recompilation of the formula will yield a different result. > The bug (as explained above) should be easy to fix I love it when people who do not know the code and implications say "should be easy".. > > Best use defined label ranges, > > Sheet -> Named Ranges and Expressions -> Labels... > Yes, but they are clumsy No, they are the correct way to use labels. Anyway, I'll come up with a fix for this situation (no text content above/below and empty cell below and numeric cell to the right leads to a row label), which of course *might* break other uses of the non-deterministic automatic labels where exactly this constellation previously lead to a column label.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/61cb699e88b3680becf78dc7b8bd514b2b7318a4 Resolves: tdf#146722 Force row label for single text with numeric to the right It will be available in 7.4.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.
Pending review https://gerrit.libreoffice.org/c/core/+/129079 for 7-3
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4669ee729fd25ce36f6b2b2d501481528f9f464b tdf#146722: sc_subsequent_filters_test2: Add unittest It will be available in 7.4.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-3": https://git.libreoffice.org/core/commit/721cd0658ab9721c01be0097f71a66ff3bdad7ac Resolves: tdf#146722 Force row label for single text with numeric to the right It will be available in 7.3.1. 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.
(In reply to Eike Rathke from comment #5) > > The bug (as explained above) should be easy to fix > I love it when people who do not know the code and implications say "should > be easy".. > Yeah; sorry about that! I thought a blank cell was a simple problem.