Created attachment 130396 [details] Spreadsheet with 2 diiferent filters set In a special spreadsheet document the filter via "Search items" doesn't find all corresponding cells. For demonstation I have attached in the zip-File a spreadsheet with 2 different filters set. - both spreadsheet documents contain the same data in 2 sheets, in both documents autofilter is activated in both sheets - in the sheet "Objektiv-Datierung" of both spreadsheets is set a filter in column G via "Search items" with search for "Tegonar", 40 rows are found The difference is the filter in column D in sheet "Altix III und IIIA" - in spreadsheet "Testtabelle_Filter_V1.ods" this filter is set via "Search items" with search for "Tegonar" too, 39 rows are found, row 34 is not shown - why? - in spreadsheet "Testtabelle_Filter_V2.ods" this filter is set via Standard Filter: Field name: "genaue Bezeichnung" (this is the title of column D), Condition: "Contains", Value: "Tegonar", all 40 rows are found When I'm right, the Standard Filter with condition "Contains" should deliver the same results as the filter via "Search items" - or am I wrong? This behavior I have first found in LO 5.3.0 RC1. Actually I have reproduced it with Version: 5.2.5.1 (x64) Build-ID: 0312e1a284a7d50ca85a365c316c7abbf20a4d22 CPU-Threads: 4; BS-Version: Windows 6.19; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group and with Version: 5.4.0.0.alpha0+ Build ID: 5e0e27e758e6f7fa325f36e6e51540e10bab0fdc CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-12_23:44:54 Locale: de-DE (de_DE); Calc: group
Reproducible. Versión: 5.0.6.2 (x64) Id. de compilación: b3fbfa99158a1030fb79f0ba72b6851afc3c7895-GL Configuración regional: es-ES (es_ES) The source of the issue seems to come from the dots at the end of cell D34, they are three character dots while in D35 they are a single three dots character. Calc's options for regular expression doesn't seem to affect the behavior.
At first sight I haven't seen any differences between cell D34 and other cells in this column. But the hint to the trailing dots was good: This is the difference! After I have replaced the three single dots by a three dots character the filter via "Search items" works properly. For me the problem is resolved with this hint. But if it is not to complex it would be better when the filter function could be corrected.
Maybe a corner case, but it works improperly.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 139121 [details] Screenshot of the filter list The Bug ist still present in LO 5.4.4 Version: 5.4.4.2 (x64) Build-ID: 2524958677847fb3bb44820e40380acbe820f960 CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group and also in Version: 6.0.0.2 (x64) Build-ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL and Version: 6.1.0.0.alpha0+ (x64) Build-ID: facfc2951ea9f4745edd4a6fb1cf97697f33f40a CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-01-14_00:42:04 Gebietsschema: de-DE (de_DE); Calc: CL The first time the bug occured in LO 5.0.0, when in the filter entry list the the entry "empty" ("leer") was introduced - see in the attached screenshot. In LO 3 and 4 this entry was not present. One could filter the not empty rows only via "not empty" in the upper part of the filter list.
Dear Stefan_Lange_KA@T-Online.de, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
As I have seen only now I haven't described the bug completely correct: The filter in "Testtabelle_Filter_V1.ods" is set via Standard Filter and 40 rows are selected by the filter and in "Testtabelle_Filter_V2.ods" is set by "Search items" and 39 rows are selected. But as was written by m.a.riosv in Comment 3 it is a corner case. I have already written in Comment 5 when the problem did occur first (LO 5.0.0, when in the filter entry list the the entry "empty" was introduced). The bug is still present in Version: 6.2.3.2 (x64) Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and in Version: 6.2.4.2 (x64) Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL and also in Version: 6.3.0.0.alpha1+ (x64) Build ID: 9e0e97b716ab074d4558c76a62a66bf597f332a5 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-21_17:40:06 Locale: de-DE (de_DE); UI-Language: en-US In Version: 6.3.0.0.alpha1+ (x64) there is an new bug I will report soon: In the case of "Testtabelle_Filter_V1.ods" where the filter is set via Standard Filter a click on the blue filter arrow in column D opens the entry list with all entries selected and also "All" selected, but the click on "OK" doesn't change the selection: Only the entries selected by Standard filter remain selected.
hello @Stefan, sorry, i had seen this long time ago, didn't i comment it or is the same problem mentioned elsewhere? not a solution, but a hint where to search ... the 'special thing' with your row 34, cell D34 is "...", vs. "…" in the other rows, see the difference? first is three single dots, second one special charakter sometimes called 'ellipsoid', it's easier to see here than with the font used in your sheet, but you can check by marking it with shift+cursor-keys, had a big big problem with ex$el some time ago, 'three dots' are sometimes a killing bug for spreadsheets, don't know why, but lost month of work til i spotted that ... :-( replacing the three dots with the ellipsoid 'heals' your file, would be nice if anybody can spill some clue about background, and why auto- and standardfilter reacted different ... and maybe prepare calc to never produce such errors ...
don't be astonished about funny results, prev. comment is a hint, not the solution, there is something more buggy, e.g. exchanging cell D34 and D35 will ... filter out row 34!!!, and giving row 35 an ellipsis symbol afterwards will heal the disappearing of row 34 on re-apply of the filter ... nice quirk ...
quite sure it's boiled down to autofilter not differentiating between "…" - 'ellipsis symbol', one character!, and "..." - 'three single dots', three characters, in selection definition, but as result only displaying those elements which first appear in the data, ommitting the 'nearly identical' ones with the other symbol(s), clear bug, ver. 3.5.1.2 could! handle them distinctive, regression, bibisect request, when trying to investigate you need to switch of app. replacement in [tools - auto correct options],