When pressing the a key, keyboard_event->unichar delivers a.
caps + a => A
1 => 1
caps + 1 => 1?

So thats my roblem... I thought that when pressing caps + 1 it would deliver ! because unichar takes the modifiers into account (which it does for the letters).

Same happens with all the numbers, öäü and , . - and basically everything that isn't a plain(english?) letter.

Am I doing something wrong or is this an error/supposed to work like this?

Still on 4.9.8 btw.

Yes.
Both with capslock and pressing caps manually 1+caps turns into ! in any editor I tried (like this one).

Never ever seen that behaviour before. Probably no one else who has worked on the Windows keyboard driver has seen that before either.

Yes, arthur got it right.
The problem with allegro keyboard event is happening when using the shift key manually as well as with caps lock.
And öä etc ARE letters
If allegro is not making 1 to ! with capslock I can live with that.
But not beeing able to produce a ! at all is not so good.

Hmm... wouldn't a table be a crapload of work to implement for different keyboard layouts?

If there is a winapi function I don't know... but I thought there HAS to be one.
Otherwise I don't know how windows is knowing that it shoul make shift+1 to ! or shift+ö to Ö.

Will try to find something out.

No, the old API asked Windows directly for the Unicode character. toupper can never work.

[Edit:] That is, I misunderstood... this seems to be only for how the CAPS LOCK key works. I have no idea what that does in A4, or what it is supposed to do. but toupper sounds quite reasonable.

Does it output the same characters to the debug window, a file and the screen?

Eh... I tested only to a file myself.
Will test later and report here.

EDIT:

caps lock OFF.
manually pressing shift + letter of choice.

Edit2:
In my first post I was talking about caps. Because I thought the two keys were named "caps" and "caps lock". But obviulsy it's better to use "shift" and "caps lock"?

Ok. So it's a bug.

Just want to make sure that with character code you mean the value returned by keyboard_event.unichar?

EDIT:
I noticed another bug.
When the first letter that is entered into an allegro app is pressed together with shift ALL letters from now on will be converted to uppercase letters.
This happens with the allegro example too.

Steps to reproduce:

start ex_keyboard_events
press shift + a => A (correct)
press b => B (wrong)
press c => C (wrong)
(even shift is not pressed from now on all letters are uppercase letters)

This happens not when the first letter is not entered with shift
REstart ex_keyboard events
press a => a (correct)
press shift + b => B (correct)
press c => c (correct)

I just looked at the Windows keyboard code, and it's completely broken... we don't handle keyboard state properly at all. To have e.g. SHIFT+A produce a capital A, there is a check if allegro's shift key is pressed, and then toupper is used to convert an a into an A

Also the whole idea of receiving DInput events, but then calling GetKeyboardState for each single event instead of using the event information is kinda flawed.

My advice would be, completely get rid of the DInput keyboard driver and replace by something which is much simpler, has much better performance (although that likely will not matter for handling key pressed), and works 100% perfectly:

Listen to the WM_KEYDOWN/WN_KEYUP/WM_CHAR messages and generate Allegro's events from those and only from those. Anyone here has Windows and wants to code it?