aj wrote:
> - There's a problem with Allegro registering a key press (pause I
think)
> when it regains focus after having been unfocused.
[snip]
anyhow, i have also found something.
in allegro 4.1.15 in /src/win/wkeybd.c line 140-ish there is some code
for PAUSE key
in the older 4.1.14 same file, line 140 there is no PAUSE key code.
the problem was introduced in 4.1.15
the change log for 4.1.15 says
"Eric Botcazou made KEY_PAUSE work properly in windows."
This indeed was the problem. It appears as though a Pause key event gets
into DirectInput's buffer when the app is switched out. Attached is a
possible fix, which I didn't test all that much.
Peter
cvs -z3 -q diff -u src\win\wkeybd.c
Index: src/win/wkeybd.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/win/wkeybd.c,v
retrieving revision 1.23
diff -u -r1.23 wkeybd.c
--- src/win/wkeybd.c 4 Jul 2004 13:44:50 -0000 1.23
+++ src/win/wkeybd.c 19 Sep 2004 16:09:32 -0000
@@ -141,10 +143,21 @@
/* emulate PAUSE scancode sequence */
if (scancode == DIK_PAUSE) {
- int i;
- _handle_pckey(0xE1);
- for (i=0; i < 5; i++)
- _handle_pckey(0);
+ int i;
+
+ /* DirectInput appears to get DIK_PAUSED events when the app
+ * loses focus, with pressed = false. Don't pass these fake
+ * events on, or they will end up in the readkey() buffer
+ * when the app regains focus. I didn't find any reference
+ * to any such behaviour on the net, though... --pw
+ */
+ if (!_key[KEY_PAUSE] && !pressed) /* hacky */
+ return;
+
+ _handle_pckey(0xE1);
+ for (i=0; i < 5; i++)
+ _handle_pckey(0);
+
return;
}