Re: [AD] Windows keyboard state bug in 5.0.2.1 when switching display?

[Omar Cornut <omar@xxxxxxxxxx>]

> > - Keyboard works fine most of the time, however keyboard events seems to
> > be "missed" by Allegro internal processing after/during a display change
> > (it is probably a short amount of time?)
>
> Indeed. The keyboard state functions are implemented on top of the
> events in the Windows version right now, they have no extra information.
> (And events are generated in response to WM_KEYDOWN messages of the
> Win32 API.) I don't know a lot about the Windows port, but likely those
> WM_KEYDOWN messages are only generated when there's a window - so I'm
> not surprised it can go out of sync while re-creating the display
> (meaning there's a short time without any window).
>
> To fix your use case we could create fake release events for all
> currently held keys when the last display is destroyed. Or maybe even
> better read the actual keyboard state from Windows and make it
> completely independent of the events (if Windows has a function for it).

It was working fine with Allegro 4, maybe because Allegro 4 was using 
DirectInput for keyboard whereas Allegro 5 relies on the message pump?

Another thing is that the PrintScreen key (corresponding to VK_SNAPSHOT 
at Windows) level is never received by the Allegro 5 application. This 
post suggest it requires a specific hook to retrieve this key via the 
message loop:

http://www.gamedev.net/topic/255399-windows-hooks-eg-wh_keyboard_ll-must-be-in-dll/

I am positive that this was working in the Allegro 4 implementation as 
well. Using GetAsyncKeyState() one I can retrieve this keypress outside 
of Allegro.

(Note that in my use case I don't want to hijack the Windows print 
screen feature, I merely want to be able to identify when the key is 
pressed to do my own snapshot as well)