Sigh. Let me try to explain.

So if the numpad Enter was pressed, I get the other Enter as a bonus? That's just wrong. I don't want to special case the Enter keys in my game, I want Allegro to take care of it. And currently it does that just fine.

From reading MSDN docs, I'm pretty sure that neither GetKeyboardState, GetKeyState, nor GetAsyncKeyState can actually do what you want here, as there is no bit for the extended key flag. In other words, this cannot be done properly.

What I think you should do is this:

1. Clear all keys.

2. Update the toggle modifier keys.

Nothing more. Don't update the non-toggle modifiers either, just clear everything. It's consistent, less code, easier to maintain. And games don't use the modifier keys as modifiers, they just use them as any other key.

Another thing you can do: Update the toggle modifiers in the keyboard driver initialization, this is missing. And, yes add the missing keys in update_modifiers.

I did read your new patch before replying, and it does update the keys in basically the same way. So what I said still applies.

Unless you generate "fake" events to sync it up, the state and the events will be out of sync anyway. This is not a big deal. Just forget about this.

I think that you need to stop for a bit, go back and actually read and understand the code, starting here.

And then do some testing with ex_keyboard_events, pressing different kinds of keys on your keyboard. See what ALLEGRO_KEY_* codes they generate. Especially the extended keys, and the numpad keys, with Num Lock on and off, etc. Because your patch does not give the same ALLEGRO_KEY constants as the event system does.

Please make some effort to understand how things work. It's hard to create a good patch if you don't know what you are doing. I improved and bugfixed some of the Allegro Windows code, and to do that I had have a good understanding of it. I am not making things up when I say that your patch has problems.

I guess, but I shouldn't be coding since my left shoulder is fucked up for the time being

I thought I had given pretty exact intructions how to do this, but I don't seem to get through

No. The state cannot be properly updated, so don't try either. See this.

EDIT:
Well, there is the possibility that the array that GetKeyboardState returns actually contain all the keys, even the ones that don't have their own VK codes. But someone would need to figure this out first. In that case, it can be done.

The problem here is that in my opinion, you're displaying quite the annoying and immature attitude and I'm tempted to simply ignore you (I am aware of the fact that this makes me seem immature as well but you're not exactly making this easy).

You also seem to fail at understanding the very limited scope and purpose of this small patch in this thread.

I also doubt you tested the new patch because if you had, you would have noticed that the state is being correctly reported by al_get_keyboard_state after switching back in because after the fire-just-once-on-switch-in update it is immediately based on the event maintained state afterwards which already was correct before the patch (before the old one which has already been reverted).

I explained why the state can not be cleared on switching out.

There are other issues. Those can be addressed in another patch outside of the scope of this one as described in the OP.

The state can be properly updated in that case, because the respective function to do so to acquire the state from the Windows API is called within the correct thread. Please stop spreading false information.

The only case where it would not work correctly (by system design) is when the Window does not have input focus. That's consistent with the event driven system however so it's a non-issue.

No, it does cause the key state to be synchronized with the key state that the windowing system (Windows) intends for the application.

An application is not intended/supposed (by the system) to know of any keys being pressed while it does not have input focus. It is also not supposed to get key up messages while it does not have input focus. It is only supposed to know the last state as it was when it lost focus.

When it gets focus back it is only natural that you need to press a key again to get another key down message or in this case an updated state (which you will get correctly even by al_get_keyboard_state because the Windows events will update the state after that initial correction).

It's not optional. If shift is not pressed anymore after switching back in, pressing just P should not still report shift. That's what this patch fixes.

There are other issues (which I repeat, this patch does not address, I lost count how many times I stressed that).

For example, if a key is being held while switching in, the event system never gets a key-down and thus it can't be correctly reported in the state.
To fix that the hw_to_mycode array would have to be further decoded/filled but then al_get_keyboard_state would be more accurate than the event system causing another inconsistency, unless we'd also use the information from them to generate a couple of fake (Allegro)events after switching in.

This would then not be consistent with the default behavior of Windows applications only relying on (Windows)event (not Allegro Events) based input.

But again, that will have to be fixed in a separate patch.

Okay, looks like I'll be up all night anyway...

Is this your original issue? Like said earlier: just clear the state (as in the_state) on switch in. With a single call to memset(). That's it. In addition, I would call update_toggle_modifiers().

Now I think you're just looking for mistakes in my posts Like I said: Windows does not seem to give you enough information to do this through the keyboard state API. Only through window (WM_KEYDOWN etc.) messages. Would be nice if it did, but finding out requires testing as it's not documented. And I think just clearing all keys (except the 3 toggle modifiers) is a good solution, instead of updating some keys but not others.

Just for fun I tried confusing the Allegro 4 game Saucelifter by switching in/out while holding keys, etc. And it didn't take much to mess it up. This is just for illustrating the problem, I know we are talking about Allegro 5. It's just not going to be perfect no matter what we do. But it can be made a bit less noticeable.

Of course it does. It's just that Allegro presents a different view of the keyboard, which requires some extra information to create (I have already explained this, please don't ask again). The Windows keyboard state stuff is probably very old, and they haven't updated the API to match the capabilites of the window message system. Maybe because they expect people to use one of the event/message systems instead. Which is what both A4 (yes, it does) and A5 does.

It's not really broken. It's just that you can't hold down a key while switching to your A5 game and expect it to register. You switch to it, then start playing. Not a big deal, and I wouldn't be surprised if many non-Allegro games behave like this. It's just that you don't notice, because you generally don't do this unless you are testing you keyboard input system

What you would notice is keys that get "stuck" in the pressed state. Clearing the key state fixes that. Which is why I keep suggesting it.

Does other GUI systems do this? I have no idea. That's a different discussion than this anyway. At least it's a different patch.

This code is taken from the 'key pressed' event handler in wkeyboard.c that torhu linked to:

   /* Check for an extended key first. */
   my_code = 0;
   if (extended)
      my_code = extkey_to_keycode(vcode);

   /* Map a non-extended key.  This also works as a fallback in case
      the key was extended, but no extended mapping was found. */
   if (my_code == 0) {
      if (vcode == VK_SHIFT) /* Left or right Shift key? */
         vcode = MapVirtualKey(scode, MAPVK_VSC_TO_VK_EX);
      my_code = hw_to_mycode[vcode];
   }

Allegro aims to represent ALLEGRO_KEY_ENTER and ALLEGRO_KEY_PAD_ENTER as two entirely separate keys. But let's look at how Allegro does that:

• We get ALLEGRO_KEY_PAD_ENTER from the 'extkey_to_keycode' function in the case where vcode is 'VK_RETURN'. This only happens if 'extended' is set.

• We get ALLEGRO_KEY_ENTER from the 'hw_to_mycode' array, which is only used if the 'extkey_to_keycode' part didn't work correctly. So it doesn't happen if my_code has already been set to ALLEGRO_KEY_PAD_ENTER.

• ALLEGRO_KEY_ENTER appears in slot 0x0D. I checked, and VK_RETURN is 0x0D. So Windows must provide both Enter keys via the same VK_ constant, but with an 'extended' boolean to differentiate.

This is from Dennis's patch:

+        for (i = 0; i < 256; i++) {
+           if (win_key_state[i] & 0x80)
+              _AL_KEYBOARD_STATE_SET_KEY_DOWN(the_state, hw_to_mycode[i]);
+           else
+              _AL_KEYBOARD_STATE_CLEAR_KEY_DOWN(the_state, hw_to_mycode[i]);
+        }

When that loop hits i==0x0D, it will update ALLEGRO_KEY_ENTER. But it's possible that Windows will have set win_key_state[0x0D] if ALLEGRO_KEY_PAD_ENTER is held down. If so, then ALLEGRO_KEY_ENTER will be set incorrectly. Have you checked for this?

Even if the loop doesn't introduce an error here, it is still incomplete, as it will never set the entry for ALLEGRO_KEY_PAD_ENTER (because ALLEGRO_KEY_PAD_ENTER doesn't appear in the hw_to_mycode array).

(The other thing I was going to mention is that the loop indiscriminately writes garbage to the_state[0] for all the keys with no entries in hw_to_mycode, but then, the existing code does that too.)

Right - now that all that is said:

torhu, you're in danger of driving away a possible contributor. You could tweak your explaining-fu as follows:

You've stated that Allegro "takes care of it" so you don't have to "special case the Enter keys". You should say exactly what Allegro does, which is to treat the Enter keys as separate unrelated keys.

In order for this to make sense, you have to explain what the extended key flag is.

If you don't get through, don't shout louder. On the contrary, if you make the effort to explain, then Dennis will either reach the same conclusion or win you over to his view, and no one will need to use any underlines.

You're absolutely right to defend Allegro 5's best interests - don't stop doing that - just find a more diplomatic way to do it.

[APPEND]
Tomasu, Dennis and elias, on the subject of broken state:

If I'm playing a game and something like Windows Update or a calendar reminder pops up and steals focus, then there are a number of things I'd like the game to do:

• Pause if it's a real-time game - this is ideal and can be accomplished if the game uses events. It can hook the 'focus lost' event.

• Release all keys if it's a non-real-time game - then I don't run the risk of a 'use resource' operation auto-repeating, a puzzle map scrolling way further than I wanted it to, etc.

When I go back to the game, I will happily release and re-press a key if I was holding it and it doesn't respond the first time. This is accepted behaviour, as is very rare anyway since the default physical state of a keyboard is 'all keys up' anyway.

On the other hand, if my player is moving to the right the whole time, it isn't intuitive to have to press the right arrow again to stop the movement. I usually naturally try to fix it by pressing the left arrow first a few times, which you can imagine accomplishes nothing and is quite frustrating.

So pragmatically speaking, the 'broken state' torhu is recommending is a very practical option that will make all real users happy. It's a perfectly good solution if Dennis's approach can't be implemented safely, and it's definitely better than accidentally setting state for a key that isn't held down.

(Nothing wrong with the state API. Just fix the bugs, as you would in any other piece of code. Forcing your users to worry about mismatched KEY_DOWN and KEY_UP events, just because Windows does, is on the other hand quite negligent. I would advocate synthetic KEY_UP events on focus loss, perhaps optional but enabled by default, or perhaps flagged as synthetic inside the event object. Oh yeah, another thing that might be good if it's not currently possible - the ability to get the full keyboard state as it was at the time of the current event, as opposed to the latest possible state.)

And you can do that yourself. I just don't think we should make it impossible to get correct keyboard state/events in the case of switch outs.