| Inconsistencies with selection in a table via keyboard [message #1777773] |
Mon, 04 December 2017 14:36  |
 Gunnar Adams
Messages: 49
Registered: May 2016 |
Member |
|
|
Hi,
in our application we are using a special compound widget made up of a text, button and dropdown containing a table.
The reason for this was, that we needed to implement a combobox capable to display multiple columns.
In this widget we observe the following behavior, which we have tracked down to a seemingly inconsistent behavior in the RAP implementation of the Table widget.
I will try to describe what happens:
Initially, above described combobox has no selected value (selection is empty). The table in the dropdown therefore correctly has no table row selected.
We therefore expect the first key press of Cursor-down to select the first table row.
Problem 1: it doesn't. It selects the second row instead.
Selection of the first line by keyboard is only possible by pressing Cursor down followed by Cursor up. Pressing the Spacebar in order to select the first line may also work, but is a bit counter-intuitive.
Problem 2: When we have selected a value in this combobox, pressing the Delete key removes the selection again. The combobox again has no selected value (correct). When dropping down the combobox, we still see a highlighted row in the table (in the hover color).
It seems that it is the FocusItem which is not affected by the deselectAll and that both table.setSelection(-1) and table.setFocusIndex(-1) will do nothing as they only accept the range from 0 to count-1.
The JavaScript code seems to rely on the FocusItem for it's keyboard handling and I suspect that this is the reason, why there is always a tableitem (either the first one or the last selected FocusItem) which is internally selected. When pressing cursor down, the next item after this focusitem is then selected.
The expected behavior would be (for a single-selection table):
1. If there is no selection, pressing the Cursor-down key should behave as if the return value of table.getSelectionIndex() = -1 is incremented by one and the resulting item index is selected.
2. The FocusItem should be reset to a reasonable (intuitive) value in either deselectAll() or setSelectionIndex(-1). The highlighting of the previously selected (Focus?)item after deselectAll() is unexpected. Is this (the focus state) a themeable color?
We require the hover styling for selection of the values when using the mouse.
Question: Is the behavior described above a bug or by design? I understand, that, in a non-empty table, there has to be a FocusItem, but the keyboard selection logic should work based on the actually selected line.
How about the following as a fix: If the selection is empty, return the current focusitem upon Cursor-down, if the selection index corresponds to the current focusitem, return the next tableitem.
Best regards,
Gunnar
|
|
|
|
Powered by
FUDForum. Page generated in 0.02827 seconds
] 
Search
Help
Register
Login
Home
