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.
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
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 4.3.0.0.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 4.3.0.0.beta1 -> oldest version from my testing Yes, I have italian translation of LO and I don't know the exact term used in enghlish. thanks!
** 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 5.0.2.2 or later) https://www.libreoffice.org/download/ 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) http://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: 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 5.0.1.2 (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. ***
Still. Version: 7.0.0.0.alpha0+ (x64) Build ID: 95ec2e9b024ff12a3005777c902d7e0975460b1d CPU threads: 4; OS: Windows 10.0 Build 19592; UI render: Skia/Raster; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL
*** Bug 138264 has been marked as a duplicate of this bug. ***
I've investigated the problem described in Comment 9. I've fixed it locally and will soon submit a patch.
I've submitted a patch to gerrit: https://gerrit.libreoffice.org/c/core/+/113991 Waiting for review
scito committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c7f64973c0ac985c9506f660d93d0762d898f3bc tdf#84517 show count of non-filtered rows in sc status bar It will be available in 7.2.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.
Verified with filtered rows, thanks Arch Linux 64-bit Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 3199182588fecac8a1c1fe202ca55702a3aab6ab CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 23 April 2021