LCL ComboBox sucks ...

[ArminLinder]

Hi all,

the LCL combobox does have what I consider a nasty behavior: if the input box is focused, and you hit the left "Shift" key, the dropdown of choices will

a) drop down, and worse
b) grab the focus

I consider this odd, because using shift-tab do travel through form elements is quite common in Windows. Tabbing forward works like always, but if one starts his Tab-reverse journey in a Combo-box, he ends up in the list of selections. Just try it: place a Combobox on a form, and an edit before and after it (tab order). Now, if starting from the edits, you can nicely tab and shift-tab through your form. If you, however, start with shift-tab in the Combobox, you won't go to the previous edit, but to the Combobox dropdown list.

I tried to work around this using onKey methods, but had no luck, it seems that the key handler of the dropdown does not honor the combobox onKey(up/down) event handlers, since when I try to suppres left-shift (Key: 16 + ssState) by returning Key := 0; notig changes, the dropdown does still open.

Anyone having an idea how I can get around this behavior?

Thx

Armin.

[derek.john.evans]

true. When using AutoDropDown, a TComboBox drops during a KeyDown event, so, pressing shift triggers a dropdown.

Disabling AutoDropDown, and using this seems to work better:

Code: Pascal  [Select][+][-]

1. procedure TForm1.ComboBox1KeyPress(Sender: TObject; var Key: char);
2. begin
3.   (Sender as TComboBox).DroppedDown := True;
4. end;  
5.  

Looks like AutoDropDown might need a rethink.

[Blaazen]

true. When using AutoDropDown, a TComboBox drops during a KeyDown event, so, pressing shift triggers a dropdown.

Delphi 7 does not do it. No modifier key opens combo. So it can be bug-reported.

[ArminLinder]

true. When using AutoDropDown, a TComboBox drops during a KeyDown event, so, pressing shift triggers a dropdown.

Disabling AutoDropDown, and using this seems to work better:

Code: Pascal  [Select][+][-]

1. procedure TForm1.ComboBox1KeyPress(Sender: TObject; var Key: char);
2. begin
3.   (Sender as TComboBox).DroppedDown := True;
4. end;  
5.  

Looks like AutoDropDown might need a rethink.

Thanks for the fix, it works very well. Bug filed.

Another issue: if AutoComplete is on, Enter/Tab does not leave the input, if the dropdown is open. instead, it closes the dropdown, next Enter/Tab leaves the input. I tried to find a fix, but whatever I tried so far, it had other unwanted side effects.

Tab and Enter should, in my opinion, accept the current suggestion, fire onEditingDone once, and proceed to the next form element ...

Thnx, Armin.

[ASerge]

Tab and Enter should, in my opinion, accept the current suggestion, fire onEditingDone once, and proceed to the next form element ...

I have the opposite opinion. User thinks: the component shows me nearly my choice item. Okay, I got it, let's close the hint (click tab or enter) and I will type (or select) exactly what I wanted... uh, but where's the focus ?
By the way, Delphi does the same, ie first closed drop-down list, and the next time moves focus. With AutoDropDown=False it's working as you want.

[ArminLinder]

Tab and Enter should, in my opinion, accept the current suggestion, fire onEditingDone once, and proceed to the next form element ...

I have the opposite opinion. User thinks: the component shows me nearly my choice item. Okay, I got it, let's close the hint (click tab or enter) and I will type (or select) exactly what I wanted... uh, but where's the focus ?

Hm, my users do work/think a little different, it seems. If they select from the list, this does, in their opinion, mean that they have seen an !exact! match in the list. If there isn't an exact match in the list, they won't use the list at all, but simply continue typing.

If you think that way, double-Tab-bing in the Combobox is one Tab too much, and they tell me they feel hampered.

Maybe this comes from what my application does: 99% of the time the list does contain what they are looking for, so the combobox is only like a list to select from. The text field of the combo is not meant to input something new, but the quickest way to select ... just punch in the first few characters of what you are needing, 90% of the times, after 2-3 characters, the item you need is on top of the dropdown then, Tab, gotcha. When it isn't, 9% of the time the item is just below the item highlighted (partial match from left), press cursor-down a few times, tab to select, gotcha. If the item needed is farther than say 2-3 cursor-downs than the currently highlighted list they will rather add another character, to bring the highlight closer to the desired item, than scrolling the list using the cursor keys. I have noticed that most do even type characters until they have an exact match, then tab, done.

There is 1% left (in my scenario), when there isn't a match in the list. Nobody I observed tries to select something from the list to edit it afterwards, if what they need isn't in the list they simply keep on typing. And I do the rest: if they leave the combo with something not already in the list, I dynamically add it, so they have it next time.

But user habits may differ :-)

And like you said ... I'll have to do more testing with different settings in AutoSelect and AutoDropdown, maybe I can find a combination which fits my needs better.

Amrin.

[ArminLinder]

This control, sorry, is almost unusable for my purposes. My objective was to create a text entry field with a self learning autotext feature, just like most browsers have it nowadays.

Next 3 issues: cbactRetainPrefixCase/cbactSearchCaseSensitive don't work as expected (where it isn't easy to tell what to expect, because of a quite flimsy documentation). And: one [Backspace] key press deletes the complete input field, when the mouse is used to enter the text field, even though the AutoSelect marker is cleared. And the cursor position is broken, if you switch from mouse to keyboard input.

Issue #1: up/lowercase problems

Steps to reproduce: drop a combobox and a button onto a form. The button does not get any code, it's just there to move the focus away from the combobox. ComboBox settings:

AutoSelect:true
AutoDropdown:true
cbactEnabled: true
cbactEndOfLineComplete: true
cbactRetainPrefixCase:true
cbactSearchAscending: true
cbactearchCaseSensitive:true

fill the items list with some entries (names), add one with a case  typo, like "JaGGger, Mick". Now try to correct this typo in the input field.  If you do, correctly, enter "Jagger, Mick", the input field (thanks to cbactRetainPrefixCase:true) will accept this, but if you exit the control ([Tab], click button) the text will revert to "JaGGer, Mick". No matter what arcane navigation I tried, I never managed to get "Jagger" after exiting the Combo-Box. Seems that on exit the cbactRetainPrefixCase:true and/or cbactearchCaseSensitive:true attribute is not honored.

Delphi XE7: unfortunately: same behaviour.

Now on to issue #2:

click on the button to move the focus away from the combobox. Now come back to correct the typo: click the mouse just behind the "GG", and click again to clear the AutoSelect, and hit Backspace to clear the "G".  The whole input field is cleared.   Note that you can correct the "GG" typo, if you move into the text field using the keyboard: set focus on the button, [Tab] or [Shift-Tab] until the combobox input field highlights, hit [Right-Arrow] to clear the Autoselect, hit [Left-Arrow] to position the cursor behind the "GG", and now you can use [Backspace] to clear the "GG".

It won't help you much, though, since as soon as you hit [Tab] to exit the field, Mr. Jagger will revert to "JaGGer" due to issue #1. 

Delphi XE7: not an issue.

Issue #3

if you change cursor movement from mouse to keyboard, the control looses the cursor position. To reproduce, position the cursor behind the "GG" using the mouse, now press [Left-Arrow] to advance the cursor left: the cursor will jump to the end of the input field and then advance left 1 character to the 2nd character from the end.

Delphi XE7: not an issue.

Armin.

[Michl]

I make some work on TComboBox and AutoDropDown. Now Lazarus Trunk (revision 54056) and Lazarus Fixes should behave like Delphi (tested Win32, GTK2, Qt4). I make it Delphi Berlin compatible as much as I can see. Now only four keys should be different than in Delphi: <Up>, <Down>, <PgUp>, <PgDown>. These keys still open the DropDownWindow with AutoDropDown = True. To prevent this, you can do something like:

procedure TForm1.ComboBox1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  if Key in [VK_UP, VK_DOWN, VK_NEXT, VK_PRIOR] then
    ComboBox1.DroppingDown := False;
end;

Please report, if I miss something.

Thank you