English > Support

small problems with alphabetical sorting and with autocompletion

(1/2) > >>

Anson:

problem with alphabetical sorting

When the list of movies, actors or some grouped listing are sorted, it is done strictly according to the charset (ASCII?). This results in listing all uppercase titles first, followed by lowercase titles. While people use the complete titles without moving "The" to the end of it, and while using english titles (usually all words are capitalized), this doesn't matter much, but when there are lots of German (or french, italian, etc) titles, and/or when moving articles to the end, many titles suddenly appear at the end of the movielist instead of being alphabetically sorted together with the capitalized words. Similar also applies to special characters like "-", "'", "(", etc, and also to special local characters like äöüÄÖÜß, èéêùúû, etc which partially appear before uppercase, between upper and lowercase, and after lowercase.

It would be nice to be able (either by default or selectable by an option) to sort all special chars together at one place (either before or after all other chars), and most of all to sort chars according to the local language or in some other merged way, at least ignoring upper and lowercase, or even eg AaÀàÁáÄä together, followed by Bb, etc


problem with autocompletion

In my database, I have added several custom items, including "select list". When I want to select a value in such a list by typing the first few chars, two effects occur:

The chars i type are taken literally including uppercase and lowercase, and autocompletion only takes the rest of the string from the selection list. Since the typed chars are taken as typed but it looks as if the field was automatically filled with an existing value, I already ended up several times in unintentionally creating a new value which I couldn't easily see (because of the sorting problem, see above).
Example: A value "Disney" already exists in the selection list, but i simply type "d". Autocompletion makes "disney" from it, and when i accept, a new value is created. Sorting or grouping by this field will later cause this new value to show up at the end behind all uppercase values (A ... Disney ... Z ... disney) and the record seems to be missing in the database when i look at the "Disney" group.
It would be nice when case would also be adjusted automatically, although i recognize the problem of "how to add a new value starting with different case if a value starting with those letters already exists"
I have no perfect solution for it, but wanted to explain the small problem i have with the current situation. Maybe in the meantime, autocompletion could match the exact case only, which would require a little more carefulness (also using the shiftkey instead of "just typing"), but avoid unintentional additional values.

Another problem with autocompletion is a bit more strange:
In a custom select list, i have (amongst others) the values "Horror - King", "Stephen King", and "King Kong". And here is what the autocompletion does:
- on typing "step", I get "stephen King"
- on typing "horr", I get "horror - King"
   (both as expected, with lowercase problem: see above)
- on typing "stephen ", I get "stephen "
- on typing "horror ", I get "horror "
   (both: why is the rest no longer completed when i type the space?)
- on typing "stephen ki", I get "stephen king Kong"
   (rest is completed again, but: what kind of completion is THAT?)
   (at least i had a good laugh on Stephen's new nickname :-)
- on typing "horror - ki", I get "horror - ki"
   (rest still is no longer completed after i type space and "-",
   and it is also not even completed as above like "horror - king Kong")

Is the autocompletion done by PVD by doing some patternmatching, and the regex and stringoperations cause also unintentional matches like the "Stephen King Kong"? When i programmed something with a listbox in one of my programs, i set flags to ignore case and to alphabetically sort the list. When I type something in the editfield of that dropdownlist now, it doesn't show autocompletion, but opening the pulldown or using wheel or cursorkeys shows the first value which matches these typed chars, making it easy to use mousewheel or cursor-up/down to select an existing value (including the correct case of the characters), and the preselection of a value speeds up scrolling to the intended value, most importantly in very long lists.
Of course, this is only my personal approach in one of my programs, but for my style of working, it worked out: type a few chars (without watching for correct case), use the wheel or cursor (even a single "down" will do), and get to a correctly spelled existing value fast. For these abilities and less other problems, i would gladly sacrifice a shown autocompletion :-)


ps: another small general problem with the select lists is that after editing a record, typing a new value for a select list, and applying the changes, this value won't be considered for autocompletion on editing another record later, unless i have first clicked the arrow to pulldown the selection list at least once: The list of values seems to not be updated automatically, and i have to force such an update by showing the list manually once.

rick.ca:
Sorting of data is done by Firebird, not the program.

The primary purpose of the program is for managing downloaded data. For the relatively rare cases where data entry or the changing of downloaded information is required, I think the list behaviour is fine as is.

Anson:

just like with my other post, you picked those parts which are less important, and didn't say anything about the other parts, eg what you think of autocompletion not working when it hits on "word - anything" or that it generates autocompletions like "Stephen King Kong" ... I don't want to "attack" someone or something, and that i use the program should be proof enough that i like it in general, but only commenting on some points which you find "fine as is" and not saying anything about the others, might give the impression as if nothing I wrote would have some real base for reporting.
even when i can live for now with those glitches (or eg autocompletion generating new values with different capitalization instead of selecting only existing values), shouldn't I report them to be addressed in some future versions ?



--- Quote from: rick.ca on October 02, 2009, 09:29:10 am ---Sorting of data is done by Firebird, not the program.
--- End quote ---

I don't know Firebird, but are there no options to tell Firebird some details like numerical or alphabetical sorting, sorting by local charsets instead of ASCII/Unicode, maybe even specify a custom sorting procedure, etc ?


--- Quote ---The primary purpose of the program is for managing downloaded data.
--- End quote ---

including to retrieve data and look up movies, use groupings, sorting on some field, etc !?!


--- Quote ---For the relatively rare cases where data entry or the changing of downloaded information is required, I think the list behaviour is fine as is.
--- End quote ---

as i said in the subject line: "small problems"

i think that data entry or editing is not as rare as you think. I myself will have to edit each movie record, eg to modify the (localized) title, to add info about my sorting (like movie groups, etc) and my storage folders, and to add info on the type of media/DVD/file/etc, for a total of 15000+ fields (including 9000+ select lists) on the first 3000 movies. And that has nothing to do with list behavior, but with the autocompletion.

the normal use (looking up movies, displaying groups, etc) is related to "list behavior" and as soon as I have localized all titles, my guess would be that half of them are lowercase and half are uppercase. together with possible errors from wrong capitalization on select fields (and i wanted to use select fields instead of short text fields just to avoid typing errors), I don't consider it "fine as is", but only "can live with it"

rick.ca:

--- Quote ---...shouldn't I report them to be addressed in some future versions ?
--- End quote ---

Sure. But if you do expect these things to be addressed, report them in a manner that respects the fact there are very limited resources for doing so. So, list autocompletion, for example. While the facts you've reported are probably correct, it's a very minor issue. If it's going to be addressed, it will be because your concise post is readily understood and recognized for what it is, added to some todo list, and then considered along with other issues and suggestions when that part of the program is next reviewed for possible improvements. If it takes nostra longer to read, assess and debate a suggestion than it would to simply implement it, it's not likely the suggestion is going anywhere.

Having analyzed it so thoroughly, you know full well the list autocompletion matter barely qualifies as a bug. It's probably not affecting anyone else, or they would have said so. Now that you understand the behaviour, you can easily adapt to it. So, no immediate action is required, and you're not in need of assistance. This is a straightforward suggestion for the improvement of a program function that should be posted as such in Feature Suggestions. You may do so any way you like, but I'm sure you'll find the more concise the better. If nostra has any question about the suggestion, you can elaborate then. If your suggestion is readily understood, you'll also find other users will add their support. You'll know you've communicated a good idea successfully when they simply post "+1."

The sorting issue is another example of something that has been reported and discussed in the past. I don't expect everyone to find such previous discussions, but you obviously have no aversion to research. Directing a little bit of that effort towards the use of the forum's very effective search function would be worthwhile. An understanding of where a particular issue stands will put you in a better position to contribute something new and useful to the discussion. Even if you don't find past discussions about an issue, try to respect the fact some things are so obvious they must have been discussed before. If that's the case, it would be more respectful to lead with a question (e.g., "I just noticed [this behaviour]. Is there a reason why it works that way?") before launching into your own problem analysis and recommendations.

patch:
Anson, your analysis of the problem is clear and thorough. I agree it is a deficiency in PVD which significantly impacts on the ease of use of its user interface. Improving the sort order presented to the user would be a useful enhancement.

It is true it has been superficially discussed in the past.

--- Quote from: rick.ca on October 02, 2009, 09:29:10 am ---Sorting of data is done by Firebird, not the program.

--- End quote ---
Is rick.ca summary. Which I believe is misleading.
Firebird could be programmed to present the data in what ever order was desired. See http://www.firebirdfaq.org/faq244/
The valid point is it is not the default firebird sort order.


--- Quote from: rick.ca on October 02, 2009, 09:29:10 am ---The primary purpose of the program is for managing downloaded data. For the relatively rare cases where data entry or the changing of downloaded information is required, I think the list behaviour is fine as is.

--- End quote ---
rick.ca This comment comes across as: "I don't want to use PVD that way so nostra should not waste his time doing this and instead do things which are important to me"
In the interests of encouraging broad discussion as opposed to argument, please consider first exploring other users perspective prior to writing it off. You never know, a new forum member may go on to make a valuable contribution to PVD.

Navigation

[0] Message Index

[#] Next page