Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Basing autofiltering on the result set, not all rows. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | belzecue <andrew> | ||||||||
Component: | ui | Assignee: | frank | ||||||||
Status: | CLOSED FIXED | QA Contact: | issues@sc <issues> | ||||||||
Severity: | Trivial | ||||||||||
Priority: | P3 | CC: | issues, kpalagin, kyoshida, ooo, openoffice, pagalmes.lists, pobox, www.openoffice.org, yoshimit, youssef | ||||||||
Version: | 680m32 | ||||||||||
Target Milestone: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- | ||||||||
Developer Difficulty: | --- | ||||||||||
Issue Depends on: | |||||||||||
Issue Blocks: | 77677 | ||||||||||
Attachments: |
|
Description
belzecue
2004-04-13 16:35:11 UTC
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.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. *** |