Listbox item selection fails (Access 2002/SP2)

Topic

New Reply

I have been creating Access applications since release one. Up until now selecting items in textboxs or comboboxs via the keyboard has functioned as it should: Pressing a key will select the first item starting with that key; pressing a second key will select the next item whose second key matches; and so forth until the item wanted is selected.

Then the t&c box key matching in my current application (heavy VBA code) stopped working at the third key. An example: 1) The listbox of composer names opens and displays the beginning of the list. I press lower case “l” and it selects “Lalo” as it should. 2) I press “i” and it selects “Liadoff” again as it should. 3) Then I press “s” expecting it to select “Liszt”. Instead it inserts an upper case occurrence of the letter in the selection box (creating “LiSadoff” which doesn’t match anything) and positions the list back to the first entries. I must exit the application to clear up the mess it’s gotten itself into. All my other Access applications are fine. Any ideas of what has happened?

Thank you, John

Reply | Quote

Replies

Do you have a KeyDown, KeyPress or KeyUp event handler for the control or at the form level (if KeyPreview is True)?
Do you have active Timers in your application?

Reply | Quote

Does this only happen with this one combo box, or all of them? If only one, is it possible there is an input mask for that control?

Reply | Quote

Thank you HansV and MarkLiquorman for your replies. Your questions have led me to discover patterns: There are three forms. The one that contains no keystroke interceptions is working correctly. The other two forms contain a KeyDown at the form level with the Key Preview property set to Yes. All listboxes and comboboxes on these forms are exhibiting the deviant behavior described in my initial communication. A Pattern! However, sticking an Exit Sub statement at the top of their KeyDown Subs shows that the logic contained in those procedures has no bearing. One (only) of these two forms also contains a KeyPress routine that simply forces every key entered to upper case. Finally, no Timers or input masks are used.

I look forward to more of your questions as I am again stumped. John

Reply | Quote

What happens if you (temporarily) disable form-level keyboard handling by setting Key Preview to False?

Reply | Quote

As you suggested, I set the Key Preview form property to No. Now the listbox sellection by keystrokes works as it should. Of course, also now the facilities provided by the disabled procedures do not work. (Executing routines upon identifying Cntl-A and Cntl-R key combinations.) Any ideas why Key Preview is sabotaging my list and combo boxes? And any ideas on how to work around it?

Thanks, John

Reply | Quote

It might be a timing problem. There might be one culprit, but it’s also imaginable that all that checking combined causes the problem. Finding out is probably going to be a tedious job. You could do the following:
Make a copy of the form.
In the copy, remove ALL code that checks KeyDown, KeyPress and KeyUp. Turn KeyPreview back on. Hopefully, things will still work correctly then.
Then, start putting checks back ONE by ONE, testing after each addition. When the problem reappears, see if there is something special about the latest addition. Remove it, and try adding another bit. that way, you’ll find out if there is a single piece of code that causes the problems, or the combination.
Good luck – this kind of problem can be tough.

Reply | Quote

The problem is solved; it was caused by KeyPress. KeyPress changed each lower case character internally (<< significant word) to upper case. The procedure was defined "Sub Form_KeyPress(KeyAscii As Integer)" and the statement doing the conversion was "KeyAscii = KeyAscii And &HDF". This casued no problems when the data tables were all in upper case (left over from a main frame system). Some months ago the data was converted to lower case and the problem must have started then. Why the combo box key matching worked for the first two keys but failed with the third, I have no idea. But now that I've stopped the case conversion it's fine.

Thank you for all your suggestions. John

Reply | Quote