[AD] [ alleg-Bugs-2241109 ] Keyboard events ignore shift/capslock under Windows

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #2241109, was opened at 2008-11-08 11:26
Message generated for change (Settings changed) made by elias
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2241109&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core Library
>Group: 4.9
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: SiegeLord (siegelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Keyboard events ignore shift/capslock under Windows

Initial Comment:
When retrieving the keyboard event via ALLEGRO_EVENT, and checking the pressed keycode via unichar field of the keyboard event, the retrieved character is unaffected by shift/caps lock keys as it should be. This does not happen under Linux: when shift is pressed, for example, you get the capital version of whatever key you have pressed.

I couldn't verify this independently via ex_keyboard_events as examples, so far, have refused to run for me...

----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2009-04-23 20:48

Message:
It's not fixed - using toupper is compltely wrong, we must use the unicode
value Windows reports. Usually there is not only Shift, but also a
third-level modifier, and in most languages also dead keys. The only two
possible ways are to use ToAscii (it's not so easy to get it working with
DInput though, must do it like in A4). Or simply don't use DInput at all
for keyboard input.

I think we can make life a lot easier if we don't use DInput for keyboard
input - but not sure. Is there any advantage from using DInput for keyboard
input?

----------------------------------------------------------------------

Comment By: SiegeLord (siegelord)
Date: 2008-11-10 15:38

Message:
The shift keys work now, but the capslock does not. Upon further testing it
appeared that the problem lies deeper than initially suspected. On Windows
(i.e. not on Linux, and likely not on Macintosh) the keyboard seems to
ignore any software changes to the layout and sense of the keys. I.e. it'll
always think that you have an English QWERTY keyboard regardless of the
settings of the Keyboard/Language section of the Control Panel. This means
that if you try to enter text in some sort of different layout, or under a
different language, you will find that the old letters are registered
instead.

----------------------------------------------------------------------

Comment By: Trent Gamblin (trentg)
Date: 2008-11-08 20:23

Message:
Should be fixed. Can you report back on it after trying current svn?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=2241109&group_id=5665