Re: [AD] win_set_window doesn't work with keyboard input in Windows

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


I apologize for reposting this message, but it has been a while since I originally posted it, and I was wondering if anyone is going to do anything about it.


I posted this in the Allegro main mailing list, and Trent suggested
that I bring it up here.

Problem:

 Under Allegro 4.2.2 on WinXP SP2, attempting to use readkey or ureadkey
 with win_set_window does not return the correct values. After the first
 successful readkey/ureadkey call, the state of key_shifts will never
 change. This manifests by the key returned by one of the readkey
 commands always being lowercase. Numlock does not properly translate
 numpad keys either.

 Details of Allegro Environment:

 The 4.2.2 release of Allegro is being built under Visual Studio 2003,
 using the Visual Studio projects and solutions found in the
 allegro/build/msvc7 directory. The December 2006 install of the DirectX
 SDK is being used.

 The program itself was also built under Visual Studio 2003.

 Reproduction:

 The following program is a small test case that can be used to detect
 the presence/absence of the bug. The #define switches between the two
 build modes. If CAUSE_BUG is 0, then the code will use Allegro's window.
 This mode is shown to work. If CAUSE_BUG is not 0, then the code will
 create a window and use wnd_set_window. This mode will not work.

 Steps (please follow these to reproduce the bug):

 1. Build the executable with CAUSE_BUG set to 0.
 2. Run the executable.
 3. Maneuver the Allegro window and the console window such that they
 have minimal overlap. This is for ease of viewing.
 4. Click on the Allegro window to give it input focus.
 5. Press a few letter keys. Notice that the letters appear in the
 console window in lower-case.
 6. Hold shift and press a few letters. Notice that the letters appear
 in the console window in upper-case.
 7. Build the executable with CAUSE_BUG set to 1.
 8. Run the executable.
 9. Maneuver the two windows such that they have minimal overlap. This
 is for ease of viewing.
 10. Click on the non-console window to give it input focus.
 11. Press a few letter keys. Notice that the letters appear in the
 console window in lower-case.
 12. Hold shift and press a few letters. Notice that the letters /do
 not appear in upper-case/. Hence the bug.

 You can also repeat the CAUSE_BUG=1 steps where you press one of the
 Shift keys as the first key you use. If you do that, then all of the
 letters will be uppercase, even if you do not hold them down. And the
 word shift will always be present.

 Notes:

 While this particular code does not test what happens when the keyboard
 is in polling mode, my actual application does use polling and it does
 not work there either.

 Also, I have recently discovered that mouse input using similar code
 does not work. That is, the mouse input code is broken in the same way
 as readkey/ureadkey.

 Additionally, be advised that the CAUSE_BUG=1 version of the program
 creates a window that is not a good Windows window. If the first key you
 press is one of the control keys, then





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/