https://bugs.winehq.org/show_bug.cgi?id=55446
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Alexandre Julliard from comment #3)
(In reply to Dmitry Timoshkov from comment #2)
(In reply to Alexandre Julliard from comment #1)
(In reply to Dmitry Timoshkov from comment #0)
Under Windows SendMessageW(LB_FINDSTRING) works just fine regardless of system locale.
Of course that depends how we define "works just fine" ;-)
It means that LB_FINDSTRING returns index of the correct listbox item.
There's no single "correct" answer for case-insensitive string matching.
In which case returning an expected item index could not be correct?
I agree we don't want to use the C locale, but should it use the user locale instead? Or the thread locale? Or the default Unicode mapping table? Some tests would be interesting.
I'd guess that listbox is supposed to use the locale set by LB_SETLOCALE like it already does in other places of the code, that way it used to work before the problematic commit.
It never used the locale for partial matches, it was using the default Unicode mapping table.
It uses the locale for exact matching, but it's not clear that this is correct either, because there are no tests, and because we didn't support locale-specific matching when the locale support was implemented. This really needs proper tests.
Probably that kind of tests should have been added during the code changes similar to the commit that introduced the regression. It doesn't look fair to request adding the tests from the reporter of the bug. Are you planning to ask the commit author to add the tests to make sure that the proposed changes don't inroduce the regression, or revert the commit otherwise? :)