Bug 84517 - UI: wrong number of selected rows in status bar when rows are filtered
Summary: UI: wrong number of selected rows in status bar when rows are filtered
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.0.beta1
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
: 96344 119115 121551 (view as bug list)
Depends on:
Blocks: Statusbar
  Show dependency treegraph
 
Reported: 2014-09-30 15:48 UTC by flavio
Modified: 2019-04-12 09:21 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description flavio 2014-09-30 15:48:00 UTC
The new feature introduced in calc 4.3.2.2, that shows the number of selected rows and columns in status bar, counts in the number also rows and columns that are collapsed. This behaviour is different form what happens with the SUM feature, also reported in status bar, wich includes in the sum only visible (expanded) cells.
Comment 1 ign_christian 2014-10-01 03:03:18 UTC
Hi Flavio.. If I understand correctly what you meant is counting of selected rows/columns respect hidden rows/columns, while SUM not.

Steps to check:
1. Fill cells A1:B3 each with 1
2. Select row 2 > right-click > Hide
3. Select cells A1:B3

Results in status bar: "Selected 3 rows, 2 columns" "Sum=4"

So if we want consistent results, should be: "Selected 2 rows, 2 columns"

*) Same results applied with hidden columns

If that's what you meant, I can confirm such behavior with LO 4.3.2.2 and 4.3.0.0.beta1 under Ubuntu 12.04 x86
Comment 2 flavio 2014-10-01 06:43:26 UTC
That's exactly what I mean. The behaviour is not consistent. Both with hidden cells and with collapsed cells (F12).
Comment 3 ign_christian 2014-10-01 07:23:52 UTC
(In reply to comment #2)
> That's exactly what I mean. The behaviour is not consistent. Both with
> hidden cells and with collapsed cells (F12).
Sorry..I just realized what you meant by collapsed :)

Confirmed. Same behavior if row 2 collapsed on step 2 in comment 1

Lets set version 4.3.0.0.beta1 -> oldest version from my testing
Comment 4 flavio 2014-10-01 07:31:05 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2015-10-14 19:56:09 UTC Comment hidden (obsolete)
Comment 6 flavio 2015-10-15 16:02:34 UTC
still present on 5.0.1.2 (x64).
Windows 7 SP1 64bit
Comment 7 Aron Budea 2016-09-14 05:32:55 UTC
*** Bug 96344 has been marked as a duplicate of this bug. ***
Comment 8 Aron Budea 2016-09-14 05:35:26 UTC
See the duplicate bug report for a bit of discussion on this.
Some options are outlined here: https://bugs.documentfoundation.org/show_bug.cgi?id=96344#c9
Comment 9 Eike Rathke 2018-03-22 11:32:24 UTC
For hidden rows/columns this is not a bug. There effectively *are* 3 rows selected in the original example, a selection span includes hidden rows/columns. When copying the selection to clipboard and pasting somewhere else the hidden rows are included.

This is different for filtered rows though, where the status bar also includes the rows filtered out, but if copied to clipboard the filtered-out rows are not included. Keeping the bug for this, adjusting summary.
Comment 10 m.a.riosv 2018-08-06 22:13:57 UTC
*** Bug 119115 has been marked as a duplicate of this bug. ***
Comment 11 Xisco Faulí 2018-08-06 22:32:21 UTC
Just for the record, the feature was added in https://cgit.freedesktop.org/libreoffice/core/commit/?id=82b5ded699fcc03a09b0930213da204a332285e6
Comment 12 m.a.riosv 2018-11-20 23:15:30 UTC
*** Bug 121551 has been marked as a duplicate of this bug. ***
Comment 13 Colin 2018-11-21 07:42:56 UTC
I am experiencing the same (bug 121551) but also, noted that if the sheet contains a couple of thousand rows and 40+ columns then the value summaries -total, average- of the selected rows also appear to be calculated on the total value of all the cells in the unfiltered range. As noted, cutting and pasting to a new "unfiltered" location, sheet, document, produces the correct summaries.

The summaries are also impacted if the filtered rows are sorted on one of the other filters. Sorting on the actual filtered column then rectifies the summaries. There are some fairly definitive screen images attached to that closed report.

It would also surprise me if this is not a cause of the printing anomaly whereby the "end of page" for the printed output is "erratic" - some pages in the multi-page document will contain perhaps 10 lines whilst others may be only 1 or 2 lines short of a full page and not quite so noticeable.

If it's of any assistance, I can provide a completely anonymised sheet with 3000+ rows of actual data, where the personal information is encrypted - but still sortable. Definitely no GDPR issues and masses of permutation possibilities.
Comment 14 m.a.riosv 2019-04-12 09:21:04 UTC
*** Bug 124701 has been marked as a duplicate of this bug. ***