Bug #7779
ChUI Swing: focus does not move backward with Shift-TAB key
0%
History
#1 Updated by Vladimir Tsichevski almost 3 years ago
In ChUI mode when I press Shift-TAB, the focus jumps to the previous widget in the tab order, but returns back in the same moment.
OE does not show anything similar.
#2 Updated by Greg Shah almost 3 years ago
What testcase?
#3 Updated by Vladimir Tsichevski almost 3 years ago
- File 7779.p
added
Greg Shah wrote:
What testcase?
7779.p attached.
#4 Updated by Alexandru Lungu almost 3 years ago
Eduard, can you please check if this is caused by your recent focus changes?
#5 Updated by Eduard Soltan almost 3 years ago
Alexandru Lungu wrote:
Eduard, can you please check if this is caused by your recent focus changes?
Probably not, because I reverted my changes and still can reproduce.
#6 Updated by Vladimir Tsichevski almost 3 years ago
- Status changed from New to Feedback
The difference is in the LinuxKeyboardReader: instead of one keyboard event it generates two events: one for key pressed and another for key typed.
The first event with the key code BACK_TAB (509) causes the correct move focus to the previous tab stop reaction, but the second with the key code TAB (9) causes the move focus to the next tab stop reaction, which is not expected.
The following lines in the keyPressed is the origin of this:
// normal VK_TAB is generated naturally in keyTyped() but SHIFT +
// TAB must be handled here
if (code == Key.VK_TAB)
{
code = shift ? Key.VK_BACK_TAB : -1;
}
If the Shift-TAB was entered, then an event with Key.VK_BACK_TAB is generated, if no Shift was pressed, when no event is generated at the key pressed stage.
Constantin, can you comment on this? Bzr says these lines are yours?
#7 Updated by Vladimir Tsichevski almost 3 years ago
The following patch removed this asymmetry with the TAB key and seems to cure the issue. I consider this as an urgent workaround since I do not know why this asymmetry was introduced first of all.
@@ -201,9 +202,13 @@
int code = -1;
int key = evt.getKeyCode();
- boolean shift = evt.isShiftDown();
boolean alt = evt.isAltDown();
+ if (key == Key.VK_TAB)
+ {
+ return;
+ }
+
// escape is never returned as 27, instead it sets some state as a
// modifier key
if (key == KeyEvent.VK_ESCAPE)
@@ -220,14 +225,7 @@
if (mappedCode != null)
{
code = mappedCode.intValue();
-
- // normal VK_TAB is generated naturally in keyTyped() but SHIFT +
- // TAB must be handled here
- if (code == Key.VK_TAB)
- {
- code = shift ? Key.VK_BACK_TAB : -1;
- }
-
+
if (code != -1)
{
if (alt)
@@ -455,6 +453,11 @@
code = 31;
}
}
+
+ if (ch == Key.VK_TAB)
+ {
+ code = evt.isShiftDown() ? Key.VK_BACK_TAB : Key.VK_TAB;
+ }
// normal processing: the preprocessed character is returned directly
if (code == -1)
After patching, the TAB Shift-TAB events are completely ignored by keyPressed, and handled by keyTyped.
#8 Updated by Vladimir Tsichevski almost 3 years ago
Another issue in ChUI native mode: pressing Tab and Backtab sometimes does not work as expected:
- can cause no visible effect instead of moving focus
- can cause the
Inserttext appear/disappear in the lower right corner of the screen. - can cause the
[Zinserted into the characterFILL-IN.
#9 Updated by Vladimir Tsichevski almost 3 years ago
- File 7779.mp4 added
ChUI Swing: another issue: the CursorDown key moves the cursor outside the destination widget area.
See the 7779.mp4 video. In this video I press CursorDown then CursorUp keys.
#10 Updated by Vladimir Tsichevski almost 3 years ago
Another issue in ChUI (both Swing and native).
In OE ChUI the Home and End keys move focus to the first and last widget in the tab ring correspondingly.
In FWD the Home key move the FILL-IN cursor to the leftmost position, and the End button seems to do nothing.
#11 Updated by Vladimir Tsichevski almost 3 years ago
Another issue with ChUI (both Swing and native).
In OE pressing the Ctrl-R key cleans the screen to an empty string and sets the cursor to the rightmost or the leftmost position, depending on the alignment.
In FWD the value is cleaned OK to the empty for a date FILL-IN, but all for other types the value is set to ?.
Also the cursor is not moved for any FILL-IN type.
#12 Updated by Vladimir Tsichevski almost 3 years ago
Vladimir Tsichevski wrote:
Another issue with ChUI (both Swing and native).
In OE pressing the
Ctrl-Rkey cleans the screen to an empty string and sets the cursor to the rightmost or the leftmost position, depending on the alignment.In FWD the value is cleaned OK to the empty for a date
FILL-IN, but all for other types the value is set to?.
Also the cursor is not moved for anyFILL-INtype.
A small correction: the Ctrl-R key causes the recall action, and restores the fill-in contents to the initial value (which is not always an empty string). Otherwise, the issue remains the same.
#13 Updated by Vladimir Tsichevski almost 3 years ago
Another issue:
In OE in character mode error messages are displayed in the message area.
In FWD a message box is displayed.
This holds both in Swing and native modes.
#14 Updated by Vladimir Tsichevski almost 3 years ago
Yet another issue in FWD ChUI:
I invoke a button, which causes an action, which causes an error, which raises an error message box.
I close the message box, and a (probably, the offending) FILL-IN is displayed as focused, which is not expected.
The button, which causes the error, is also looks like focused, and is really focused (which is expected).
So, two widgets looks like focused at the same time.
Also, when I move the focus between two buttons with navigation keys, the focus "jumps" to this FILL-IN for a fraction of second.