English > Support

small problems with alphabetical sorting and with autocompletion

<< < (2/2)

rick.ca:

--- Quote ---You never know, a new forum member may go on to make a valuable contribution to PVD.
--- End quote ---

You're missing my point entirely. Anson has demonstrated his ability to thoroughly test and analyze the behaviour of the program. If I didn't believe he could make a valuable contribution, I wouldn't waste my time pointing out how he might present his findings and suggestions more effectively. It not effective to ignore previous discussions about an issue (e.g., sorting of data is done by the program). It's not effective to make a big deal of a minor issue so the developer has to spend more time sorting out the controversy than he would just making a simple change or fix. It's not effective to criticize a program function outside it's intended purpose (i.e., if you don't agree on the purpose, make that the issue).

Speaking of being effective... You imply a resolution to the sorting issue is not hampered by the fact sorting is done by Firebird rather than the program. I'm sure most users would welcome a fix if one is available. But you also indicate you're aware of previous discussions about this, so you know my "misleading" response is based on nostra's last word on this. So what is the purpose of your comment? It hardly seems a productive approach to guiding nostra towards the resolution of a long standing issue that would clearly be a valuable contribution to the program.

patch:
The order data is presented from a program can always be controlled be the programmer in any general purpose programming language.
What varies it the effort required to achieve it and the benefit to the application functionality.

So forum discussions can usefully address the benefit to a variety of users of a feature suggestion. Anson has done a better job than past posts to elucidate the issues, & I thought deserved support.

As for the difficulty in implementing a solution, only nostra can judge that but firebird does offer some native support:
Case insensitive sorting has been added to firebird 2.1 http://tracker.firebirdsql.org/browse/CORE-972
There is also the ability to support character set ordering other than the default ascii order http://www.destructor.de/firebird/charsets.htm

Given nostra past comments I suspect he may consider it at the next major program revision, depending on other priorities, feature popularity and implementation difficulty.

rick.ca:

--- Quote ---As for the difficulty in implementing a solution, only nostra can judge that but firebird does offer some native support...
--- End quote ---

Thank you. This moves the subject forward. I have no idea where to, but it seems to be worthy of nostra's consideration. If not, it's at least a legitimate question.

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."

Anson:

--- Quote from: rick.ca on October 04, 2009, 09:50:26 am ---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."
--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page