Posted by: Anson
« on: October 04, 2009, 01:06:15 pm »I note from the reference provided the "solution" seems to be language-specific. That suggests to me it's a lot more complicated than just modifying the code to take advantage of a new feature in Firebird that does the sorting "properly."
Each language and each country has different charsets and sort orders, and there even exist several different sort orders for german lists, eg in phone books vs. other official lists etc (eg whether spaces, hyphens and similar are counted, whether Ü becomes Ue for sorting or is sorted between U and S, etc). As long as sorting is done for one language only, it still is relatively easy, but when international movie titles are concerned which are given in many languages in a single list, all (contradicting) sort orders might apply at once. Those are the problems ...
But as long as it is used mostly eg on localized titles, the user's local language scheme might be a choice for basing the sorting on it, and even a default mapping of lowercase and uppercase might improve finding titles. I don't know about Firebird, but other systems allow a choice at least between case-significant and ignore case, or sorting according to no special charset (would sort according to the program's charset), according to an internal simple lower/uppercase merge, or according to a selection of the user (either the user's installation language or a freely selectable language).
For my purpose of not finding accidental "Disney" and "disney" at almost opposite ends of the list, any such method would do :-)
over all this talk about sorting, please don't forget that my main point should have been the problems with autocompletion:
According to what i was taught, some purposes of select lists (eg instead of using short text) should be to enable users to only use a specific set of values and to handle (select) them faster instead of typing strings slowly (this is the user's side; I won't speak of more reasons like internal management, enumeration lists, etc here). The autocompletion itself is only one (but the one nostra has chosen) of several methods for selecting values from that given set of values, and thus should not cause the set of values to be modified. And the ability to enter new values directly in that field's box (instead of having to edit the set of values in preferences or similar) is only a convenience (although an important one) to users. The fact that autocompletion in PVD is used to select existing values as well as create new ones makes it more difficult and gives lots of possibilities for problems, but nonetheless those basic principles should still apply.
Secretly modifying this set of values in any way (besides non-obviously creating new values with different case which I find highly disputable), not finding existing values and finding not-existing values defies all that and thus is a real bug in treating select lists.
While I still have mixed case in my field values and with the additional problems, i even would prefer to have no autocompletion at all (selecting values from the pulldown list instead). For me, all this is no "program stopper", but a part of the program i can't use as intended. A "feature suggestion" would only be a discussion about how to handle select boxes differently, but my first concern was that select boxes are handled correctly (either by fixing the current method or using any other method).
PS: I had written a lengthy answer to the previous 4 or 5 posts, but since the topic seems to advance a bit, I won't blow it up now here. The above was the most important, and I'll send the more lengthy reply as copy to rick and patch only