Shift + numpad arrow keys produces numbers

[Dmitry A. Kuminov]

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.

[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.

[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 ',').

[Dmitry A. Kuminov]

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