Apache OpenOffice (AOO) Bugzilla – Issue 27745
Basing autofiltering on the result set, not all rows.
Last modified: 2013-08-07 15:14:13 UTC
This is another behavioural difference between OO and Excel that you may or may not wish to emulate. The behaviour relates to autofiltering. Take, as an example, a sheet with two columns labeled 'First' and 'Second'. Both columns have three rows containing numbers 1, 2, 3: First | Second 1 | 1 2 | 2 3 | 3 - Activate autofilter on the column headers. - For column 'First' select '1' from the autofilter dropdown list. Now only one row is displayed in the sheet: 1 | 1 - Examine the autofilter dropdown list for column 'Second'. Notice that all three values (1, 2, 3) are displayed, even though, logically, there is only one row in the active result set and only one possible choice for the value of column 'Second' (the value 1) given the active filtering on column 'First'. Selecting anything other than the value '1' in the second column dropdown list results in a null result (no matching rows). In Excel, autofilter dropdown lists only show the possible values based on already-active filtering, so that it is not possible to return a null set. For example, in the above demonstration, clicking on the 'Second' column autofilter dropdown arrow would present a list with only one item: '1'. In other words, Excel bases its autofiltering on the active result set, not the original dataset/table. Cheers, Andrew Ferguson / Belzecue
Hi Bettina, this may be related to Issue 16112 but not to Issue 364 as stated there. So I re-assign this Issue to you for further Investigations. Frank
The behavior described in <a href="http://qa.openoffice.org/issues/show_bug.cgi?id=16112">Issue 16112</a> does match this issue somewhat, however I will vote for this one since the two others have been closed. <a href="http://qa.openoffice.org/issues/show_bug.cgi?id=364">Issue 364</a>, based on which <a href="http://qa.openoffice.org/issues/show_bug.cgi?id=16112">Issue 16112</a> was closed, also is relevant. The reasoning for closing <a href="http://qa.openoffice.org/issues/show_bug.cgi?id=364">Issue 364</a> was, quote: <i>Our behaviour is technically corret.</i> I would hesitate to disagree before understanding why this behavior is correct, yet my initial impulse is to insist (as respectfully as possible) that the way Excel handles this aspect of Autofiltering is more appropriate. Andrew did a perfect job describing the behavior and how he felt it needed modification, and I agree with him entirely. Believe it or not, this simple issue keeps me from migrating my spreadsheet usage to oocalc.
Sincere apologies for the href's... First time posting to a bugtracking forum.
*** Issue 39988 has been marked as a duplicate of this issue. ***
*** Issue 42315 has been marked as a duplicate of this issue. ***
Created attachment 22407 [details] Proposed part Patch
I have attached a part of the patch. The function RowFiltered is inline BOOL ScDocument::RowFiltered ( USHORT nRow, USHORT nTab ) const {
I have attached a part of the patch. The function RowFiltered is in document.hxx (added by me) inline BOOL ScDocument::RowFiltered ( USHORT nRow, USHORT nTab ) const { return pTab[nTab]->IsFiltered (nRow); }
Stumbled about this because of a mail on the dev@ list, http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=14539 The patch looks appealing for its simplicity on first glance, but it leads to only values being selectable that are not already filtered, even in columns where the original filter criteria was applied. To filter on other values, first the filter would have to be removed. This is not what the user expects. Just a small example of what would be correct instead: A | B --+-- 1 | 1 1 | 2 2 | 3 2 | 1 3 | 2 3 | 3 Filtering on column A for values of 2 would display A | B --+-- 2 | 3 2 | 1 The filter list on column B now should offer 1 and 3, this is also what the patch does. But the filter on column A should still offer all values 1,2,3 to be able to quickly select another set, whereas the patch also narrows these down to only display the value 2. Furthermore, if in this state one selects 3 for column B, the result is A | B --+-- 2 | 3 The filter list of column A should now offer the values 2 and 3, because both would be in the set of all values 3 of column B. The filter list of column B should offer 1 and 3, because both are in the set of all values 2 of coumn A. So there is quite some more work to be done for this enhancement. Eike
*** Issue 54203 has been marked as a duplicate of this issue. ***
I observed this bug on 2.0rc3 french version.
I observed this bug on the 2.0 french version. This feature is widly used in my company !
Don't forget to vote for this issue. In my company this feature is frequently used and we cannot work without this filter. My first question to this problem is long time ago and nothing has changed. What can I do that this problem been solved in the next release?
*** Issue 59898 has been marked as a duplicate of this issue. ***
My company also requires the filtering to work like Excel's, in that the second filter choices are limited to those values still present in the data set. When working with large amounts of data it is imperative to be able to tell what values are still available after filtering (rather than seeing all options in the original data set when clicking on the combo box). I hope this feature is implemented soon, it certainly has my vote.
Always occur on 2.0.1 version. This is the first feature my colleagues will test ! Is it complex to solve ? In order to plan an OO migration, do you know when this feature will be available ? Thanks.
always occur on 2.0.2 version
always occur on 2.0.3 version
The problem go away in 2.0.2 version from Ubuntu Dapper Drake Final.
This always occurs in the 2.0.3 version for GNU/Linux in french.
always occurs with 2.0.4rc3_0 for GNU/Linux !!!!!!!!
Can someone change the issue type ? I mean it is not an enhancement but a defect issue since it does not provide the expected behavior to the user. When using one autofilter, we don't want to see values which has already been discarded by an other filter.
*** Issue 20945 has been marked as a duplicate of this issue. ***
*** Issue 70506 has been marked as a duplicate of this issue. ***
*** Issue 71839 has been marked as a duplicate of this issue. ***
always occurs with 2.1.0 and 2.2.0rc1
I disagree with Eike - the filter on column B must reduce the options in the filter on column A. For me if it does not - the issue is half solved and even more confusing than now.
Set target.
why not 2.3 ?
reassigned to TBE
accepted
Please find the new spec here: http://specs.openoffice.org/calc/ease-of-use/AutoFilter_Behavior.odt
fixed on CWS calcautofilter The following files are affected: sc/inc/document.hxx table.hxx sc/source/core/data/documen3.cxx table3.cxx sc/source/ui/inc/gridwin.hxx sc/source/ui/src/scstring.src sc/source/ui/view/gridwin.cxx
TBE->FST: Please verify on CWS calcautofilter.
Created attachment 48310 [details] Testdocument for Testcasespecification
Created attachment 48311 [details] Testcase Specification
Thank you very much!!
Found fixed on cws calcautofilter using Linux, Solaris and Windows build
found integrated on master m239 using Linux, Solaris and Windows build
*** Issue 87478 has been marked as a duplicate of this issue. ***