The new feature introduced in calc 18.104.22.168, 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.
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 22.214.171.124 and 126.96.36.199.beta1 under Ubuntu 12.04 x86
That's exactly what I mean. The behaviour is not consistent. Both with hidden cells and with collapsed cells (F12).
(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 188.8.131.52.beta1 -> oldest version from my testing
(In reply to comment #3)
> (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 184.108.40.206.beta1 -> oldest version from my testing
Yes, I have italian translation of LO and I don't know the exact term used in enghlish.
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice (5.0.1 or preferably 220.127.116.11 or later)
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
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)
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: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
still present on 18.104.22.168 (x64).
Windows 7 SP1 64bit
*** Bug 96344 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 119115 has been marked as a duplicate of this bug. ***
Just for the record, the feature was added in https://cgit.freedesktop.org/libreoffice/core/commit/?id=82b5ded699fcc03a09b0930213da204a332285e6
*** Bug 121551 has been marked as a duplicate of this bug. ***
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.
*** Bug 124701 has been marked as a duplicate of this bug. ***