Bug In Combo Box - Need Work Around

I’ve discovered a probable bug in the ComboBox, that can result in significant data entry errors for users unaware of this behavior. I have submitted this to Xojo with a project file and am hoping for a quick review, but I wanted to post here to see if there is a work around. I have posted the project on DropBox and the link is:

ComboBoxIssue

The project file makes it quick and easy to duplicate (this is on Windows). Basically, the .text property of the combo box is not a reliable indicator of what is actually “displayed” in the text field. For example, our data entry specialist are very quick at entering data. They noticed that the data they were “saving” was not actually what was being “entered”. It took me a LONG time to duplicate the steps to reproduce this but I can do so reliably.

The situation is they would click the arrow to drop down the list of entries. They would then type the first character of the item they wanted (we have an A-Z list of entries), then they would click TAB and move on. The control then fills in the balance of the text from the list box (although “auto complete” is disabled). I really didn’t know this control did this and not sure it is suppose to. HOWEVER, IF they position their mouse over another entry, even without clicking on it, at the time they press tab it is that item that the controls.text property is set to, even though the text field is updated and DISPLAYS the intended value. Therefore, the displayed text can be “A-Send back to customer” BUT if you read the .Text property it might be “B-Discard at Facility”. Because item B is what their mouse was hovering over at the time they pressed TAB. I would save mycontrol.text and wholla incorrect data is stored.

Ideas on a workaround?

What platform?

Windows 7

Wow. That’s been around awhile. I tried it as far back as RB2010r5.1.

One possible workaround would be to use a PopupMenu instead of ComboBox, as long as they are limited to the choices in the dropdown.

I’m glad I dumped the ComboBox as “too limited” way back when and built my own.

[quote=59805:@Tim Hare]Wow. That’s been around awhile. I tried it as far back as RB2010r5.1.

One possible workaround would be to use a PopupMenu instead of ComboBox, as long as they are limited to the choices in the dropdown.

I’m glad I dumped the ComboBox as “too limited” way back when and built my own.[/quote]

Yep, this is crazy, I’m going to have to abandon the ComboBox. I was lucky I save the data to disk then reload the data and re-display it, otherwise we would have never found this.

This is a pretty severe bug that can result in a lot of unexpected data corruption. I would imagine that there are a lot of projects out there that are experiencing this and don’t even know it.

As a workaround, try putting this in ComboBox.LostFocus event handler:

Me.Text = Me.List(Me.ListIndex)

Which appears to at least keep the field contents in sync with what the ListIndex is.

[quote=59820:@Paul Lefebvre]As a workaround, try putting this in ComboBox.LostFocus event handler:

Me.Text = Me.List(Me.ListIndex)

Which appears to at least keep the field contents in sync with what the ListIndex is.[/quote]

Yes, I actually experimented with that, but there are some issues. If the mouse is not over the list box it throws an out of bounds exception because listindex = -1. I can correct that, but then the behavior is dependent on whether the user’s mouse is positioned over the listbox, which isn’t intuitive - the contents will be filled normally if the mouse happens to be out of the listbox’s frame, but the value will change if it is in the frame. Still not good to have the value change from what the user entered after the control loses focus (will they notice it?).

Instead of using the mouse to “open” the drop down list, tell 'em to use F4 (which is a Windows standard for this). They can also use Alt + Down Arrow. Using the mouse in this situation is counter productive IMHO.

How quickly they enter this data mind boggling, which is why it took me so long to find. Using the mouse they click the arrow, with the other hand they type the first few characters, while the typing is occurring the mouse is on its way to the next combo box below then they hit tab to commit the one they were on. Their hands never leave the mouse or the keyboard.

I also don’t like the idea that the users behavior has to change and we need to make sure everyone knows that using the mouse can cause erroneous data being saved. Especially if they click on the field, then press F4 then move the mouse below to clear the field area.

I think the best option is just to get rid of the combo box and use a PopUpMenu where I can.

The current app which I didn’t develop but which I have now supported over the past 8 years and have made many changes to is strictly “keyboard only”. Nobody uses a mouse although it can be used. Why? Because it’s faster to enter data using both hands on the keyboard. One-handed typing? I am currently developing a new app to replace that one and again, it is designed for keyboarding. Having developed many database apps over the past 25 years as well as having been a software instructor for the same period of time, I know there are times and places where using the mouse is more productive and in fact, sometimes necessary but data entry is not one of them. CAVEAT: assuming the app is designed to be keyboarded.

I do agree that it’s not necessarily productive to force users to change their habits as it involves a re-training/learning curve which can affect QOS; however, implementing a different “method” to accomplish the same task might also involve a behavioral change.

My OP was intended as a suggestion and I simply offer the above to support it.

[quote=59941:@Rick Yerex]The current app which I didn’t develop but which I have now supported over the past 8 years and have made many changes to is strictly “keyboard only”. Nobody uses a mouse although it can be used. Why? Because it’s faster to enter data using both hands on the keyboard. One-handed typing? I am currently developing a new app to replace that one and again, it is designed for keyboarding. Having developed many database apps over the past 25 years as well as having been a software instructor for the same period of time, I know there are times and places where using the mouse is more productive and in fact, sometimes necessary but data entry is not one of them. CAVEAT: assuming the app is designed to be keyboarded.

I do agree that it’s not necessarily productive to force users to change their habits as it involves a re-training/learning curve which can affect QOS; however, implementing a different “method” to accomplish the same task might also involve a behavioral change.

My OP was intended as a suggestion and I simply offer the above to support it.[/quote]

Thank you for the input Rick. I agree with you. They do have to use the mouse for other activities. The only issue I have there is no way to force them to use the keyboard to select the item in the list box. Having the data entered properly therefore becomes a condition of where the mouse happens to be positioned at the time they hit TAB. So even if I tell them “don’t do that” there is no guarantee of data purity because nothing prevents them from doing the exact opposite, which results in corrupted data. Especially if a new user starts to use the software and doesn’t get the “message” to only use the keyboard. I’d lose sleep wondering if they’re following the rules.

If I change the application to use the PopUpMenu it guarantees the system cannot insert erroneous data based on what would appear to the user as random events. They certainly can select the wrong data - but that is definitely a user error not an application bug that corrupts the data.

Read Text in keyup when the tab is released ? With some degree of luck it will prevent hovering from changing the data ?

heh … ain’t that the truth! (you can lead a horse to water but ya can’t make it drink)

I do understand your dilemma … best of luck in solving it.

Unfortunately, the TAB key does not fire the KeyUp event for the control. The control appears to lose focus on the key down event of the TAB key, so it has lost scope and the KeyUp doesn’t fire. Bummer, I am finding no way to trap the actual text in the combobox’s text property.

You must return True in Key Down to enable Key Up to fire.

At any rate seems to me that is where you can do something. If for some reason neither key down nor key up are available, I do not see where you could catch the tab…

[quote=60334:@Michel Bujardet]You must return True in Key Down to enable Key Up to fire.

At any rate seems to me that is where you can do something. If for some reason neither key down nor key up are available, I do not see where you could catch the tab…[/quote]

Yes, I included return true, the side affect is you now cannot tab off the field AND the up event does not return the proper keycode for the TAB Key. This control is hosed…

Regardless, thanks very much for the suggestions!!

[quote=60336:@Joseph Evert]Yes, I included return true, the side affect is you now cannot tab off the field AND the up event does not return the proper keycode for the TAB Key. This control is hosed…

Regardless, thanks very much for the suggestions!![/quote]

Last idea : When user presses tab, focus goes to the next control, right ? So you can validate teh combobox text entry in that control GotFocus event, before the mouse has a chance to change things. You may need to use some flag to make sure focus came from the combobox and not directly by a mouse click…

Yes, the focus moves, but if you read the contents of the ComboBox.Text it is NOT what is actually displayed in the text box, but which entry the mouse was hovering over at the time the user pressed tab. So the on screen text may say something like “Send Rescue Squad” but if you read the actual text property (combobox.text) it will read “Search And Destroy” if that is the entry where the mouse happened to be at the time of the TAB. So, if you store combobox.text to a database you will be displaying one thing and storing another!

It appears the text field is not really what is being stored “behind the scenes” if you will but more connected to the listindex property. The underlying issue, I believe, is that the listindex property is being updated on mouse over rather than mouse click event.

Based on my fiddling with this control and seeing how it behaves I WILL NEVER use a combo box again. Unfortunately I have a ton of code that sets the value of the text property on database record retrieval, which is not easy with a popupmenu (that property is read only).

I just tried to understand better by experimenting with a small project. When user moves down the list with arrows and validates with Return, the ComboBox text is updated correctly. When user presses Tab instead, text is not updated.

I don’t know if this can be considered a bug or a feature, but I see better now where your users could generate errors.

You may want to file a bug report.

In the meantime, you may want to use a TextField instead, and modify it’s content with up and down arrows : that way the users will see the actual value selected ; when they press tab, the good value is in the field.

The values could simply be sorted in an array…

I don’t know if this would be acceptable, but it would prevent errors and not require too much change in the UI.

FYI, if you want to play with Joseph’s example, it is in <https://xojo.com/issue/31761>. I tried a combination of KeyDown/MouseText/Text, but could not come up with something that was 100% reliable.