Created attachment 180879 [details] the example announcede in the report If textual content of cells only consists of deciomal digits, it is not correctly treated as text by comparators in standard filter. In fact no comparator except "=" seems to return 'true'. The attached example is showing filter dialogs and the respective results. The cells below D1 should show "1", "17", "18", "19" if the compartison is correctly sone as needed for texts. In case of one of the expectable errors of a numeric comparison or a comparison like used for NaturalSort, the single returned value should be 1 or "1". The actual result is "no match". Column Q is showing the correct result obtained as soon as the textual nature of the contents is in addition made unmistakable by a leading letter.
Shou8ld add that the above reported results in column D are unchganged, if column A is formatted 'General' (or otherwise for numbers), and the shown textual represented numbers are returned by formulas like =TEXT(1;"0").
Reproducible Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: e4d23c27288b99c3ed3cfa332ff308b31c01f97d CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL
Dear Wolfgang Jäger, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still living in V25.2.2
It may not be welcome but in this special case I will add some comments and conjectures. The NumberFormat CODE @ is wrongly named a "format" in many places - and without exceptions(?) in the forums. However, it defintely is NOT a format, but a BLOCKING_CLAUSE telling the cell it's assigned to that entered/edited content MUST not be "RECOGNISED" (parsed) as a number or as a formula. Processing content of such cells some functions or tools obviously don't check for that clause, but apply a "recognition" themselves. This applies to CELL("format"; <reference>). It also applies in a messed-up way to filtering where the content is treated as text while the choice in the "Value" field does its own "automatic conversion". Funny: The corresponding drop-down does not. It treats textual numbers as text.