Re: [AD] Bug in readkey() with numeric keypad?

["Chris Jones" <allegdev@xxxxxxxxxx>]

> The driver was rewritten, and the documentation nowhere states the
> above behavior. So it simply was an undocumented feature.

It seems that's true ... but the approach I used to reading the keyboard was
this:

int code = readkey();
if ((code & 0xff) == 0) {
// process ASCII key
}
else {
// process extended key
}

That no longer works, because now the numeric pad keys will always be
processed as ASCII even when numlock is off; which is the reason for me
bringing this up.

> But if you look at src/win/wkeybd.c, there's some special checks for
> numpad keys starting around like 213. Maybe simply removing those
> will restore the old behavior?

I've attached a patch that fixes this. Rather than forcing NumLock to be on,
it checks NumLock and adjusts the keycode only if appropriate.

Cheers,
Chris

--- wkeybd_old.c	Thu Oct 27 23:23:40 2005
+++ wkeybd.c	Fri Dec  2 18:39:50 2005
@@ -207,57 +207,60 @@
    if (mycode == 0)
       return;
 
-   /* we always want the number characters */
-   keystate[VK_NUMLOCK] |= 1;
-   /* what's life without a few special cases */
-   switch (scancode) {
-      case DIK_NUMPAD0:
-         vkey = VK_NUMPAD0;
-         break;
-      case DIK_NUMPAD1:
-         vkey = VK_NUMPAD1;
-         break;
-      case DIK_NUMPAD2:
-         vkey = VK_NUMPAD2;
-         break;
-      case DIK_NUMPAD3:
-         vkey = VK_NUMPAD3;
-         break;
-      case DIK_NUMPAD4:
-         vkey = VK_NUMPAD4;
-         break;
-      case DIK_NUMPAD5:
-         vkey = VK_NUMPAD5;
-         break;
-      case DIK_NUMPAD6:
-         vkey = VK_NUMPAD6;
-         break;
-      case DIK_NUMPAD7:
-         vkey = VK_NUMPAD7;
-         break;
-      case DIK_NUMPAD8:
-         vkey = VK_NUMPAD8;
-         break;
-      case DIK_NUMPAD9:
-         vkey = VK_NUMPAD9;
-         break;
-      case DIK_DECIMAL:
-         vkey = VK_DECIMAL;
-         break;
-      case DIK_DIVIDE:
-         vkey = VK_DIVIDE;
-         break;
-      case DIK_MULTIPLY:
-         vkey = VK_MULTIPLY;
-         break;
-      case DIK_SUBTRACT:
-         vkey = VK_SUBTRACT;
-         break;
-      case DIK_ADD:
-         vkey = VK_ADD;
-         break;
-      case DIK_NUMPADENTER:
-         vkey = VK_RETURN;
+   /* MapVirtualKey always returns the arrow key VKEY, so adjust
+      it if num lock is on */
+   if (keystate[VK_NUMLOCK])
+   {
+     /* what's life without a few special cases */
+     switch (scancode) {
+        case DIK_NUMPAD0:
+           vkey = VK_NUMPAD0;
+           break;
+        case DIK_NUMPAD1:
+           vkey = VK_NUMPAD1;
+           break;
+        case DIK_NUMPAD2:
+           vkey = VK_NUMPAD2;
+           break;
+        case DIK_NUMPAD3:
+           vkey = VK_NUMPAD3;
+           break;
+        case DIK_NUMPAD4:
+           vkey = VK_NUMPAD4;
+           break;
+        case DIK_NUMPAD5:
+           vkey = VK_NUMPAD5;
+           break;
+        case DIK_NUMPAD6:
+           vkey = VK_NUMPAD6;
+           break;
+        case DIK_NUMPAD7:
+           vkey = VK_NUMPAD7;
+           break;
+        case DIK_NUMPAD8:
+           vkey = VK_NUMPAD8;
+           break;
+        case DIK_NUMPAD9:
+           vkey = VK_NUMPAD9;
+           break;
+        case DIK_DECIMAL:
+           vkey = VK_DECIMAL;
+           break;
+        case DIK_DIVIDE:
+           vkey = VK_DIVIDE;
+           break;
+        case DIK_MULTIPLY:
+           vkey = VK_MULTIPLY;
+           break;
+        case DIK_SUBTRACT:
+           vkey = VK_SUBTRACT;
+           break;
+        case DIK_ADD:
+           vkey = VK_ADD;
+           break;
+        case DIK_NUMPADENTER:
+           vkey = VK_RETURN;
+     }
    }
 
    /* TODO: is there an advantage using ToUnicode? maybe it would allow