Opened 10 years ago

Closed 10 years ago

#183 closed defect (fixed)

Shift + numpad arrow keys produces numbers

Reported by: Dmitry A. Kuminov Owned by:
Priority: blocker Milestone: Qt 4.6.3
Component: QtGui Version: 4.6.2
Severity: low Keywords:
Cc:

Description

Reported by Alex Tailor in gmane.org.netlabs.qt.devel:

Attempting to mark text in any QT text control using Shift + the keypad
navigation keys results in numbers being printed instead. (In other
words, Shift has the effect of simulating NumLock? instead of marking.)

This rather unfortunately makes it difficult to effectively use QT text controls...

Using 4.6.2.

I can confirm that.

Change History (3)

comment:1 Changed 10 years ago by Dmitry A. Kuminov

By default, we rely on flags when interpreting WM_CHAR messages. This, in particular, means that we interpret the key as a character only if it has the KC_CHAR flag set. In case of Shift, Control and numpad keys, I found a fancy dependency in WC_CHAR generation by the OS/2 keyboard driver:

  • When NumLock? is off, pressing numpad arrow keys produces no KC_CHAR. Pressing them with Shift adds KC_CHAR and the chr field is set to the code of the corresponding digit. Pressing them with Control doesn't add KC_CHAR.
  • When NumLock? is on, pressing numpad arrow keys produces KC_CHAR (chr is set to the corresponding digit). Pressing them with Shift removes KC_CHAR and clears the chr field. Pressing with Control removes KC_CHAR as well.

It looks like Shift temporarily inverts the NumLock? status for some curious reason. But this inversion is ignored by regular OS/2 software (and by PM classes) which seem to manually cancel it and build up the chr value on their own when necessary.

We will have to add the same exception to our code.

comment:2 Changed 10 years ago by Dmitry A. Kuminov

No, the NumLock? inversion is not always undone by the standard apps (checked e.exe and PM entry fields) -- only the one happening when NumLock? is OFF; when NumLock? is ON, all inversions reach the application as is. AFAIU, this is done exactly to make the text selection work in NumLock? OFF mode. So, we will also support only this case.

More over, undoing the inversion in NumLock? ON mode (when digits are replaced with cursor movements) would not be actually possible because, strictly speaking, a character generated by a particular key depends on the current keyboard layout (e.g. this happens with the Del key in ru_RU locale: in Latin mode, it produces the '.' character while in National mode, it gives ',').

comment:3 Changed 10 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: newclosed

Should be fixed in r802. Alex, please check and free to reopen the ticket if it still doesn't work as expected.

Note: See TracTickets for help on using tickets.