Wildcards "*" need to operate the same as Excel, especially in a formula such as =MATCH(text&"*",range,0)
I'll just add that this affects DSUM, COUNTIF and more. It seems a pretty important bug to me, since it causes libreoffice to give wrong answers when opening an Excel spreadsheet. I'm not sure what the best option is. Perhaps since there is already an option to either use regular expressions or not, there could be a third alternative, which is to use Excel-compatible wildcard matching.
For documentation, you can see:
This page doesn't make it clear where these wildcards are supported, but they are partially documented in the COUNTIF documentation:
and they definitely work in DSUM as well, which is what brought it to my attention due to wrong results in accounting spreadsheets.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
Created attachment 65565 [details]
file copied from Microsoft's documentation, demonstrating bug
This file is just a simple demonstration that libreoffice still has buggy handling of wildcards. It's an excel file that should have a value of "4", but instead has a value of "0" in the place marked with the arrow "<- ".
I've checked with libreoffice 18.104.22.168 on a debian machine, and this bug is definitely still present. I have also attached a spreadsheet demonstrating the bug, using the example from the Microsoft documentation quoted in my previous comment.
I do hope someone will look into this, since it would be great if folks could safely use libreoffice to read files generated in excel. (As I mentioned before, this caused me to misread accounting files, which seems sort of important.)
thanks for re-checking and the nice test case :-)
is prolly the code associated with this; patches are really very much welcome.
The challenge with solving this problem (I'd think) is that you don't want to break *anyone's* spreadsheet. So unless there is a simple way to tell that you're looking at an Excel spreadsheet (or one that was converted from Excel?), it's hard to know what sort of wildcards to use.
Writing code to handle MSO wildcards wouldn't be hard, but figuring out when to use them seems to me to be very hard. But maybe there is already some sort of tracking of where files originated? It's still a hard user-interface problem, since users are liable to be confused if the same formula behaves differently in two different spreadsheets...
I think it's an important bug to fix, but am afraid that it may be very hard to find a reasonable option for fixing it. :(
*** Bug 61990 has been marked as a duplicate of this bug. ***
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Removing comma from whiteboard (please use a space to delimit values in this field)
Removing entirely from EasyHack, it's not. Change needs to implement the actual wildcard search algorithm, add it to TextSearch, adapt the formula interpreter to support it and read/write the attribute from/to ODF.
*** Bug 78516 has been marked as a duplicate of this bug. ***
Change to "ENHANCEMENT".
*** This bug has been marked as a duplicate of bug 72196 ***