Created attachment 134031 [details] Sample database showing how a list box is hard to use when typing the selection How to recreate: Open the attached database, then open the form. Type a string of letters into the list box. A small list of vendors has been provided and the idea is to quickly select one using the keyboard (only). Expected result: Typing the first letters of any item should select it. Actual result: Typing the first letters of an item selects something else. I hesitated for many months before submitting this. I was hoping that since it was such an obvious issue that it was me, not it, that didn't quite get it. I can see that if you type h multiple times it steps through the items that begin with h. Perhaps for a small dataset, like 5 items, this works. But when databases get larger, and almost by definition databases are all about huge, this does not work. Thanks for looking at this.
Could not say how long the delay is, but if I type the first characters of any entry it will jump to the entry. If there is a little delay it will jump to the next entry with the chosen character as leading character. Couldn't see a chaos-result here. Tested with OpenSUSE 64bit rpm Linux, LO 5.3.3.2
Tested against Version: 5.4.0.0.alpha1+ Build ID: 5ac9c1ce61c516800cef503662d80d92394fb3f9 CPU threads: 2; OS: Mac OS X 10.12.4; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group Well, this seems to work mostly for me, depending on how fast I type the subsequent letters in the string I'm trying to enter. If I enter "ac" in quick succession, I get the first entry begining with those two letters. If I then wait a bit and enter a further letter, the first string beginning with that letter is displayed. There must be a default setting somewhere (probably hardcoded) that determines how long to wait before resetting the string sequence to null and allowing new input. Perhaps, Howard, it is this delay that you would want to have changed ? For the rest, it seems to me to work as designed. @Lionel : what do you think ? How is this supposed to work ?
(In reply to Alex Thurgood from comment #2) > Well, this seems to work mostly for me, depending on how fast I type the > subsequent letters ... Thanks Alex. I have an accounting database I built long ago and have recently ported to LibreOffice. Every month I sit with my partner to help balance her accounts and enter what is missing. Every month I'm embarrassing at how badly LO works for production entry of items with list boxes. And I have to apologize to her for how long it's taking me to keystroke the simple entries just to lookup fields like category, or payment type. It should be quick and easy and it's not. I have to fight with the list boxes. Some of the fields I was able to convert to using a Combo Box, which works much better in this regard, but it is limited to direct keyed fields, and can't currently provide a solution to indexed fields. I know it can be better because the older version of this accounting software is written in Access, and it had none of these difficulties. And before that I used something similar called chex in MS DOS (yes that long ago), and it also had none of these difficulties. When you type in the first few letters of an entry, the LO List Box should do exactly what the LO Combo Box now does well: quickly select the item you want, and without any fuss. And furthermore when you hit the delete key it should delete the entry. This also doesn't work, and I've put it in another report. In reality the combo box has so many issues that I think a major face-lift of it needs to be considered. Perhaps we should just abandon the old List Box and start over with a new control, possibly called Lookup or something like that. And when you hit the backspace it should subtract from your keystrokes (to fix a typing keystroke) without loosing your entry so far. Now I have 40+ years of working with computers, and if I'm frustrated at this control, then somethings is wrong in how it works. I can only guess that newer computer users just see it as flaky. I can understand if we don't have the technical ability (and/or the man power) do do this work right now, but that's not the question on the table at the moment. The question on the table is does this thing need someday to be improved or replaced? And if so how? I think we should begin with a list of all of the things that don't work well for List Boxes and Combo Boxes and lay out a solid plan to fix these darn things. They are so vary important in Base. I still can't get LO to build on my machine because of a bug related to MariaDB 10.1 and LO MySQL dependencies. I'm hoping that later this month when the new version of Debian is released I might be able to get past this bug and finally be able to Build LO, that is without having to walk away from my database. But even then I'm no expert in C++, but will do what I can to help with these efforts. :-)
Hi Howard, > > Some of the fields I was able to convert to using a Combo Box, which works > much better in this regard, but it is limited to direct keyed fields, and > can't currently provide a solution to indexed fields. May be you are interested in a solution how to set Comboboxes in combination with indexed fields. I have written a macro for this, because Listboxes won't provide to input new values. I wanted to have this both in one solution: Select existing values and in put new ones. I have translated the example-database from the German Base-Handbook into English. See here: http://robert.familiegrosskopf.de/lo_hb_en/Example_Combobox_Listfield.odb Regards Robert
@Howard : you are not the only one with frustrations about Base ;-) So that we can try and nail this particular one down more precisely : - did it work correctly in any of the older versions of LibreOffice, or even in OpenOffice.org 3.2.1 (or 3.3.0) ? That would already indicate whether it is something that we have brought over with us from the OOo code, or whether it is a regression that has been introduced more recently (I'm thinking dictionary suggestions here in the back of my head because that implements character analysis code in Calc that might just be being used here in the list box).
@Robert, Wow, impressive. Thanks. I'll take a good look at it. But of course it doesn't fix what we really want and need to get fixed in Base. It might however be a stop gap to make things work better for now. Sure appreciate it. BTW, would it be of any help to you (or others), since I'm a native English speaker, for me to word-smith this (i.e. the comments) and send it back to you? Also how good are you at working on LO coding? Thanks again.
@Alex Thurgood > - did it work correctly in any of the older versions of LibreOffice, or even > in OpenOffice.org 3.2.1 (or 3.3.0) ? I'll work on this. It might take me a couple of weeks (as I can only spend so much of my time on this), but I'll report back when I figure this out. Thanks.
(In reply to Howard Johnson from comment #6) > BTW, would it be of any help to you (or others), since I'm a native English > speaker, for me to word-smith this (i.e. the comments) and send it back to > you? Would be good idea. My children are laughing about my English - but it is enough to write bugs ... > > Also how good are you at working on LO coding? No, I don't know anything about the code of LO. I have only written most of the content of the German Base-Handbuch, which has also been translated in an older version into English.
I'm not sure what you mean. I open Form 1, I click on the listbox, the type "clin". I get "Clinical Laboratories of Hawaii - HiLo, HI". What else would you expect? I type "gutt", I get "Gutter Doctors, The - San Carlos, CA". I type "redw", I get "Redwood General Tire"
(In reply to Lionel Elie Mamane from comment #9) > I'm not sure what you mean. > > I open Form 1, I click on the listbox, the type "clin". I get "Clinical > Laboratories of Hawaii - HiLo, HI". What else would you expect? > > I type "gutt", I get "Gutter Doctors, The - San Carlos, CA". > > I type "redw", I get "Redwood General Tire" Agreed, and that was my experience too. Except when I introduce a slight pause between typing two contiguous characters in the string, and then depending on the delay, I either get the string I was looking for (or at least the first in a selection of strings that begin with the typed in characters) or alternatively, the listbox jumps to the entry beginning with the last character I typed in. If one's typing is not regular, say, one hesitates on the string that is being typed in, this might correspond to what Howard sees as chaos. There is clearly a lapse of time which is taken into account somehow when typing and which is interpreted in some way to decide which string the list box should jump to.
(In reply to Alex Thurgood from comment #10) > (In reply to Lionel Elie Mamane from comment #9) > > I'm not sure what you mean. > > > > I open Form 1, I click on the listbox, the type "clin". I get "Clinical > > Laboratories of Hawaii - HiLo, HI". What else would you expect? > > > > I type "gutt", I get "Gutter Doctors, The - San Carlos, CA". > > > > I type "redw", I get "Redwood General Tire" > (...) slight pause between typing two contiguous characters in the string, > (...) depending on the delay, the listbox jumps to the entry beginning with > the last character I typed in. Yes. After a pause, it is considered a new, fresh entry. That's indeed not friendly to users that are not consistent fast typists. I'm open to taking patches that improve that.
(In reply to Lionel Elie Mamane from comment #9) > I'm not sure what you mean. > > I open Form 1, I click on the listbox, the type "clin". I get "Clinical > Laboratories of Hawaii - HiLo, HI". What else would you expect? Hi Lionel, When I type "clin" I get "Clinical Laboratories of Hawaii - Lihue, HI", not ".. -HiLo, HI" > I type "gutt", I get "Gutter Doctors, The - San Carlos, CA". For this I get the same thing as you. So this case works ok. > I type "redw", I get "Redwood General Tire" For reference the table items that start with "r" are sorted as follows: ... R & R Raingutters - San Carlos, CA Radio Shack - Lihue, HI Radio Shack RWC - Redwood City, CA Redwood General Tire Redwood Lumber - San Carlos, CA Restore - Hanapepe, HI Restore - Kapa'a, HI Royal Electric - San Carlos, CA ... When I click the down arrow and then: 1) type "r" and I get: "Redwood Lumber - San Carlos, CA", but I would expect to get the first entry that starts with a "r", or: "R & R Raingutters", 2) type "re" and again I incorrectly get "Restore - Hanapepe, HI", rather than the first entry that starts with "re', or "Redwood General Tire", 3) type "red" and I correctly get "Redwood General Tire" almost by accident, 4) type "redw" and I incorrectly get "Redwood Lumber - San Carlos, CA" but I would expect to get the first item with "redw" in the name, or "Redwood General Tire"
1) the tests results I reported above were without any typing delays, in other words I quickly typed the tests. 2) Also the test result above boil down to not selecting the first item with the given prefix. 3) Then in addition to the above issue, I also think the delay is not the best way to start over. Rather I think Del or Esc (or both) would be a better, more straightforward way to undo or cancel the operation. I think Esc would be the best choice, but it must be implemented carefully because when not in the list box context, it also deletes the entire new record entry. I have learned to be careful with it, and then to cuss softly when it does delete all I have just typed in. I would like it if Esc, when pressed once would backup and erase the typing in the List Box (i.e. cancel the list box operation and close the list), and then if Esc is hit twice, that it would first backup and close the list box, then erase the new record if you happen to be on a new record, or undo any edits if you are not on a new record.
Ok, now it is time to decide, what problem this report wants to solve and edit the summary accordingly. (In reply to Lionel Elie Mamane from comment #11) > Yes. After a pause, it is considered a new, fresh entry. That's indeed not > friendly to users that are not consistent fast typists. I'm open to taking > patches that improve that. This, perhaps?
@ Alex Thurgood, I'm sorry, but I think the Summary change you just made misses is key point of the bug that I first reported here which is that there is chaos in the item selection, as clarified by this comment of mine, in answer to @ Lionel Elie Mamane's question. Perhaps you should create a new bug with your title, rather than change the title of this bug. While I think both of these should probably be fixed at the same time, there are definitely two things going on here: 1 the incorrect selection, and 2 the delay to reset. What do you think? ref: What Added Summary RemovedTyping in a list box to select an item results in chaos Improve mechanism for recognizing pauses in character string typing for entries in ListBox controls
[Well I guess I can't use tab here, as it submits my comment right away. Here is the reference I was trying to add above.] REF: What Summary Removed Typing in a list box to select an item results in chaos Added Improve mechanism for recognizing pauses in character string typing for entries in ListBox controls
Ideas: Combo Boxes work much better. Why can't the same code be used for both Combo and List Boxes? Later when the ability to delete the entry (with Del), and also the ability to hit backspace to undo a key-strokes are fixed (improved), then it only has to be fixed one place instead of two. Hope this helps.
For me, this happens intermittently.
How could the status still be "NEW" on a bug reported 5 years ago that has garnered 18 comments?
(In reply to Aaron Gerber from comment #19) > How could the status still be "NEW" on a bug reported 5 years ago that has > garnered 18 comments? NEW means it has been confirmed. https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status
It's even worse in my situation. I have entries that start with two instances of the same letter (e.g., "GG-123"), so even when I don't hesitate, the time it takes to release the key for the first character and hit it again for the second is interpreted as a pause. It would be much better if it had no mechanism for detecting pauses at all.
I'm beginning to think this problem is rooted in a problem with Windows. I just experienced the same problem when typing tags for a new topic on the ask.libreoffice.org website. Hmmm...
I'm using 7.0.6.2, and this is still a headache for me.