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.

Type some text into a text editor with caps on. Does 1 turn to !?

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

That's odd to me. Caps lock for me only capitalizes letters.

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

He meant pressing '1' WHILE pressing SHIFT outputs a '!' whether or not caps lock is on

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.

The code uses towupper from the windows api so I don't know why those accented characters aren't capitalized, if you have your locale set properly. As for 1 and ! I don't know what the intended behaviour is there. I could fix it with a table sure, but is there a winapi function that will apply modifiers to those keys?

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.

Did toupper in the old 4.2.2 API work correctly for this?

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.

I'm a little bit confused now.

Is the implementation in a5 not correct or is it not supposed to work like I want it?

What should happen when pressing:
shift + 1?
shift + ö?

What i thought what would happen is this:
shift + 1 = !
shift + ö = Ö

What currently is happening is that the chars are not changed at all:
shift + 1 = 1
shift + ö = ö

So first thing to know would what should happen?
And could it be done like it was in the old api (asking windows for the unicode char?)

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

Are you talking about having CAPS LOCK on or off?

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"?

As far as I know, what should happen is the following:

The key code returned is not affected by modifier keys. So pressing "a" returns the same key code as "shift+a" and "1" is the same key code as "shift+1". Independent of whether caps lock is on or off.
The character code depends on the status of the modifier keys. Pressing "a" returns "a", pressing "shift+a" returns "A". Similarly, "shift+1" returns "!" (depending on the keyboard layout I'm sure).
Caps lock changes the standard (un-shifted) value of letter keys from lower case to upper case. It does not affect other keys (this is true on all computers I have ever used; it's obviously not true on typewiters and I suppose there is a way to set this behavior as an option).

If the above is not the behavior you see (which I think is what you're saying), then it's a bug.

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)

Well, I guess we figured it was a Windows-port issue, but I went ahead and tested it on OS X anyway and as expected things work fine there apart for one thing - caps lock state is ignored (so pressing "a" with caps lock on produces a lower case "a"). That might be easy to fix though, and it doesn't relate directly to the Windows port problems anyway.

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?

I have Windows (obviusly ) but I'm not even able to compile allegro so I doubt I will be able to do said fix.