Description: This only occurs when the autofilter is configured to "hide" blank cells. When an entry in an autofiltered table is amended, the new value is "inserted" into the index BUT IS DESELECTED - the old value is removed. If that filter has already been defined to hide empty/blank entries then merely accessing and closing the filter dropdown will cause the new value to hide as it is deselected. Excel does not make the same mistake I believe it's more severe than just a "normal" bug because it seriously affects the integrity of subtotals. Where a user may believe they have increased the column total by (x) they have actually removed the entire value from the total. Nice if you're calculating the fuel load on the next Mars mission🤔 Steps to Reproduce: With the attached file:- Observe the values of the subtotals on row 1 set the filter for column D to exclude empty cells and confirm Observe the new row 1 subtotals for Columns E:G and that the rows with blank cells in column D are hidden Edit D4 to 75 Observe the impact on the subtotals "open" the filter on column D observe that 74 has disappeared and 75 is in the index but deselected Imagine that value had been at row 3175 in the list select OK - [Enter] to close the index Now observe the Subtotals. It gets better. Undo the filter action with the ribbon control or [ctrl]+Z ensuring that 75 is still visible but the empty cells in column D are hidden activate the filter on Column G and exclude the empty cells OK - [Enter] Observe the impact and try to imagine the nightmare when adjustments have been made on multiple columns - all set to exclude blanks Actual Results: Incorrect assessment of selected/deselected cells with catastrophic impact on the subtotals Expected Results: Correct assessments and valid subtotals Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.7.2 (x64) / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 184329 [details] Simple example .ods HT you definitely need to open the file😎
Sorry, but what is the criteria to get 75 selected? You are selecting from a list, why it should be re-selected after the change? The standard filter can do it, and seems to me, it works fine. With 'Field name' 'D' '=' 'Not empty'
(In reply to m.a.riosv from comment #2) > Sorry, but what is the criteria to get 75 selected? What is the criteria for deselecting it? If I add a line to the bottom of the array it's automatically included in both Excel and LO. If I set an Excel sheet in exactly the same manner as I did this LO sheet then Excel doesn't deselect the entry when it's edited. It is automatically included because there has been no exclusion by the user - I repeat NO exclusion by the user. > You are selecting from a list, why it should be re-selected after the change? NO, perhaps my description didn't make it clear - I made a change to an existing entry and then examined the list for other aspects and the moment I exited, LO decided of it's own volition to ignore the value because LO of it's own volition decided to deselect that new value. Excel doesn't deselect the value of it's own volition - that is the users' prerogative. I also believe that this is a NEW "feature" because I have spent two years performing the operation of amending values and hiding nulls but only recently has it started hiding real values. Initially, I thought perhaps it was me and my memory but then I performed the same task on Excel and discovered that it wasn't me going crazy, it is LO misbehaving. > The standard filter can do it, and seems to me, it works fine. > With 'Field name' 'D' '=' 'Not empty' Why would I need to play with standard filters to remedy a rogue action by LO? The slicer allows me to specify if I wish to exclude any or many items and include or exclude empty, null or zero cell values. What the slicer should not do is make those choices on behalf of the user. If I have a list of items where the value may change and I don't wish to see the ones that have reduced to zero I can exclude zero values when I filter. What should NEVER happen is that if I reduce the number then it is completely removed even though it has a value. Go shopping with 500 Euros in your wallet. Buy a shirt for 50 Euros pay for it. Look in your wallet at the next shop and discover your wallet has decided you no longer have the remaining 450 Euros. Is that how LO is supposed to work`? RE-READ the first line. If the autofilter is not set to exclude blanks it ditches the 74 and retains the selection of 75 - and that value remains in the subtotal regardless of how many times I examine the filter or deselect 225 or 450 or 62357,25 OR how many times I adjust the other slicers which only exclude entries from the same row
Sorry, but I don't know what assures the new value meets the criteria for to be selected in the list. So for me not a bug.
(In reply to m.a.riosv from comment #4) > Sorry, but I don't know what assures the new value meets the criteria for to > be selected in the list. > So for me not a bug. Did you observe the effect on the file when you change the value from 74 to 75? It must just be the same as adding a new row with the value of 75. Does LO exclude the new row just because 75 doesn't already exist in the index? Try another angle; Set the filter status to everything Add the value 12 to the bottom of the list Inspect the filter values and 12 is selected Now set the filter to exclude blanks Add the value 13 to the bottom of the list Inspect the filter values and 13 is deselected Did you change the filter from ignore blanks to ignore blanks AND any numbers between 12.1 and 14? What would you expect to happen if you cut and pasted 500 new entries to the bottom of the list? Again, for the record, Excel includes them and if the overarching desire is to be Excel compatible then I'm sorry to say it's failing
Don't need to convince me. Let see if someone else agrees with you, that's all.
(In reply to m.a.riosv from comment #6) > Don't need to convince me. Let see if someone else agrees with you, that's > all. (In reply to m.a.riosv from comment #2) > Sorry, but what is the criteria to get 75 selected? > You are selecting from a list, why it should be re-selected after the change? > The standard filter can do it, and seems to me, it works fine. Sorry to reflect on this at such a late stage but you should be aware that any action in the standard filters like > With 'Field name' 'D' '=' 'Not empty' Will override and negate any prior selections on any of the slicers on any column - All you will ever get is what matches the standard filter setting for column D
Hello, For me, when you change a cell's value, the cell needs to rest selected. And it's only when the user valides the cell's value by pressing the enter key that the selection go to the next cell.