Bug 89158 - Autofilter no longer needs Empty and Not Empty options
Summary: Autofilter no longer needs Empty and Not Empty options
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoFilter
  Show dependency treegraph
 
Reported: 2015-02-06 00:58 UTC by Pedro
Modified: 2017-12-30 21:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test for "empty" (13.81 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-12-30 13:49 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2015-02-06 00:58:42 UTC
Since developer Deena P.F. fixed the missing Blank item in Autofilter (see bug #65505) it no longer makes sense to have the two additional menu options Empty and Not Empty.
Checking and unchecking the Blank item already performs those two functions (with advantage) so the menu entries can safely be removed.
Comment 1 Cor Nouws 2015-02-06 09:40:11 UTC
Yes - but let's wait until the patch for bug 65505 is really included and confirmed.
Comment 2 Pedro 2015-02-06 10:36:47 UTC
I agree. Explained in Comment #29 on Bug 65505.
Comment 3 Kevin Suo 2015-09-21 00:37:13 UTC
Any plan to fix this? The patch to bug 65505 works perfect in 5.0.* build.
Comment 4 Kevin Suo 2015-09-21 00:54:34 UTC
(In reply to Kevin Suo from comment #3)
Actually the options Empty and Not Empty are confict with the Blank item checkbox. 

Steps to observe:
1. Open the attached document;
2. Set autofiler and select Not Empty.

--> Not Empty result are shown as expected, but when you now open the drop down list, you will see that the Blank item checkbox is marked. (At this point we expect the non-empty item checkboxes are marked)
Comment 5 Regina Henschel 2015-09-21 16:29:04 UTC
The new item "(empty)" in the lower part and the item "Empty" in the upper part have different semantics.

The new item "(empty)" in the lower part is true on empty cells _and_ on cells with an empty string. The item "Empty" in the upper part is only true for empty cells.

I have tested with Version: 5.1.0.0.alpha1+
Build ID: 88c51cd55d1a9b29e62269c53b3923770253ab07
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-09-11_13:09:15
Locale: de-DE (de_DE)
Comment 6 QA Administrators 2017-10-28 17:47:28 UTC Comment hidden (obsolete)
Comment 7 Pedro 2017-11-07 23:23:24 UTC
Un-needed items are still present in LO 5.3.7 and 5.4.2
Comment 8 Cor Nouws 2017-12-29 20:50:47 UTC
(In reply to Regina Henschel from comment #5)
> The new item "(empty)" in the lower part and the item "Empty" in the upper
> part have different semantics.
> 
> The new item "(empty)" in the lower part is true on empty cells _and_ on
> cells with an empty string. 

What is this empty string?

> The item "Empty" in the upper part is only true for empty cells.
Comment 9 Regina Henschel 2017-12-30 13:49:15 UTC
Created attachment 138747 [details]
Test for "empty"

Set a filter on column C and examine the behavior.

An empty cell is
 <table:table-cell/>
in file format.

An empty string is
  <table:table-cell office:value-type="string" calcext:value-type="string">
      <text:p/>
  </table:table-cell>
in file format.

You can have an empty string as result of a formula, e.g. ="".
You can never have an empty cell as result of a formula, because the cell content is a formula and therefore the cell is not empty.
Comment 10 Cor Nouws 2017-12-30 21:19:03 UTC
(In reply to Regina Henschel from comment #9)

> You can have an empty string as result of a formula, e.g. ="".
> You can never have an empty cell as result of a formula, because the cell
> content is a formula and therefore the cell is not empty.

thanks - didn't think if this possibility.
Comment 11 Cor Nouws 2017-12-30 21:20:38 UTC
(In reply to Regina Henschel from comment #5)
> The new item "(empty)" in the lower part and the item "Empty" in the upper
> part have different semantics.

This makes this issue invalid, or better, not a bug.