was OK in ?? (not in 3.0, I see now)

So it's not a regression (reproducible in 2.4.2)
Not even sure it's not a feature... (Some kind of Autocomplete)

@PL: what do you think?

I really thought it worked directly in previous versions.
I use it quite often. But somewhere in the last year(s) I probably got used to a
different way of working.
After
 - type A (to select Arial)
I do
 - arrow up - arrow down
and then
 - tab to next control

Not comfirmed on Windows XP  in OOO310m9 (Build:9396.)May be it fixed in this 
release.

Hi vseredkine_hitekschool,
It is this version that I see the problem in.

Have you tried it with a font, that starts with a character that has more than
one entry? (Arial, Arial Black, Arial Narrow)

I think this behaviour is not desired. 
Even more since it is not consequent when you compare to for example the dialog
for fields: When I open that
 - select the Tab Document make sure list Type has the focus
 - type an S to select Sender (English version) 
 > now Tab does bring the focus to the list Select, 
   and not to the entry Statistics in the list Type...

Indeed, this is the autocompletion of Edit fields (or in this case its
derivative the ComboBox). Indeed using tab here is a bit awkward, on the other
hand tab is one of the more commonly used keys for autocompletion.

So to what (if any) should I change the key for autocompletion ? Setting clu
from UX on CC.

@pl thanks for the explanantion.
Indeed I think that any possible change should be guided by ux.

not sure .. more consequent behavior vs. autocompletion for all

.. if you 'only' select the combobox (for further tabbing/travelling) you must
find an additional way to autocomplete (if you want it .. as pl told me,
autocompletion is the supported behavior now) that would be more consequent, but
would force an other maybe exotic keyboard shortcut? also it should be possible
than to leave the autocomplete mode with esc.

any suggestion es & mt?

set the a11y keyword

The current behavior breaks keyboard accessibility.

In the GUI, people are used to use TAB to get to the next control.

Beside that, it is very difficult with the current behavior to leave auto
completion mode. ESC will escape the dialog, not the auto completion. Return
will select the font. The only way to escape is to first use key-up/down.

IMHO the current tab auto complete feature can simply be removed.
While typing, the best match is selected in the list box, and you can use
key-up/down. I don't see any advantage in a key for only cycling in entries
starting with the matched sub string.

In case this feature really is/was meaningful in some dialog, the desired
behavior should be discussed for the specific case. So I suggest to comment out
that feature, note a date when the code can be removed if really not needed. And
if needed, we make this feature optional, off per default.

It's also surprising for the user that _nothing_ will happen on TAB, if auto
complete only contains one match.

Keyboard accessibility broken, so I set the target to 3.4.

And of course it's a defect, not an enhancement.

And that from the man who implemented the autocompletion in the first place ... ;-)

However changing an old feature just because people don't like it anymore is
certainly not fixing a defect. Anyway is everyone really happy with simply
removing this ? Also do we remove the autocompletion in only this dialog or for
every Edit field ? Simply setting a target not a specifcation does make.

Just for clarification: I just want to remove the auto completion via TAB, not
the complete auto completion feature.
The other stuff:Find matching entry when typing text, highlight entry in list
box, add remaining text as selected text at the end, should stay as it is.

which again brings us to the question: how does the user cycle through the
autocompletions if not with TAB ?

From my point of view: Not at all!

IMHO it's good enough to select the matching entry in the list box, and use
arrow keys than.

Of course this is different then auto completion, but...

UX's opinion?

@mt, pl, ..
Thanks for the discussion ;-)
for me; tab to next control and when necessary arrow down for next item in the
list is more logical.

in my opinion it is too expensive to put a good working feature/functionality
into 'trash' (i am sure a lot of people still benefit from it). as i see it now,
the bigger problem is not to run into an assumed trap, but to came out easily if
you feel trapped; so if the esc key would work properly, it would disarm the
trap situation and simultaneously keep the advanced functionality of autocompletion.

=> after inserting into a combo box the esc key must select the combo box and
not close the dialog etc. .. than you can travel further with tab.

@clu: when you say  "a good working feature/functionality"  do you mean
autocompletion or tab to cycle through the various entries?

Do many people use tab to cycle through the entries, or do they just continue
typing?

Yesterday I worked with bookmarks and then realised it is the same kind of list
box. But I never had a problem there: always I just naturally used the arrow key
to go to a next entry - if necessary. End never tried the Tab, because there is
no need in that dialog.

But OK: if there is data that supports the idea that (many) people do use the
cycle-with-tab methode, it would be better not to change it.

But then Escape to leave the autocomplete mode... what happens if there is just
one entry? Do you need to type escape then too? At the moment, with on entry,
tab directly goes to the next control.

mt->clu: I doubt that the TAB feature for auto completion is very useful here.
But if you want to keep it, you should define an other key combination instead
of TAB.

The way we handle the TAB key now breaks standard key binding / TAB handling in
GUI, which means it breaks accessibility.

Users expect to get to the next control with TAB. Especially screen readers
users can't understand what's going on when trapped in the auto completion
cycle. And everybody would fear/expect that ESC would cancel the dialog (which
also is a standard key binding).

Also I don't agree that features shouldn't be removed.

I have implemented it in the way it works now almost 15 years ago. That means it
probably was handled this way in some native Win95 GUI. I am not aware of any
system/GUI which handles it this way nowadays.

Since there seems to be no further input to this issue and the votes for
removing the "autocompletion cycle with tab" feature are 2:1, I'll remove it.

Done so in CWS vcl116

thx pl,

but to make the decision more understandable: you have not fixed the issue
because of 2:1 votes :) at least i hope so .. but the long ago discussion out of
this issue with mt's 'killer' argument which stopped further discussions: 

'The standard key binding for dialog navigation is broken, so it's an
accessibility issue, which needs to be fixed.'


bye chris

please verify in CWS vcl116

Verified in CWS vcl116.