there is a problem, if I store only the state of the keys how can I know the difference from WM_CHAR and WM_KEYDOWN messages? I mean, for example let's say that the user press the W key: it could be the action to move the player but also the action to write that letter in the chat...

Sigh. I knew I was talking too early. You have not understood what's the difference between a character and a keypress.

This is NOT implementation detail.

Sigh. It is just so sad that in 2011 people just go around with shaders and still don't understand the most basic thing of keyboard processing.

So... take notice key buttons != text generated. Text != glyph. Go to your keyboard settings and mess a bit with it. If you don't want to see, http://en.wikipedia....eyboard_layouts.

You don't mix the two together. And by the way, components typically consuming key presses are rarely involved in character processing anyway.

October 2003:
Q: I still need a good method of getting keyboard input. Does anyone have any ideas that don''t involve testing for individual keys? I''m sure there''s some way I could do this using the WM_KEYDOWN scenario
A: WM_CHAR is the way I get text input from windows. ... I wouldn''t use the WM_CHAR for navigating a GL scene though but you can use WM_KEY messages [for this]...

March 2011:
Q: What can I do to make DirectInput translate the scancodes it receives to my current keyboard layout? ... DI only registers an 'A' keypress when I press 'Q'.
A: This is correct behavior, because AZERTY(A) is QWERTY(Q). Just writing "B" on a button does not make it generate char('b'). DirectInput (as well as WM_KEYDOWN) works on "scan codes" or "virtual key codes" which are roughly "the position of the button on the physical keyboard".
It seems like you have not correctly assimilated the [color="#8b0000"]important distinctions between

1. The physical button being pressed on the keyboard ( suppose it's QWERTY(Y) )
2. The sticker applied to the button pressed ('Y' on QWERTY)
3. The character generated - 'y' or 'Y' on QWERTY, 'f' or 'F' on my layout - depending on window manager preferences.
4. The glyph associated to the character in the given context (can be pretty much everything according to TrueType management)
5. The scan code uniquely associated to the physical button pressed.

What you're doing with DI and WM_KEYDOWN is to work on (5). Which is the correct thing to do for "actions". Keyboard layout should really be considered only for text input.

July 2011
Q: Also, is there any input on which is better for mouse and keyboard input (not critical on speed just dependable) win32 or direct input. b/c direct input is a hunk of poo.
A: Yes, it is. Do not use DirectInput ... for character input, WM_CHAR works just fine. It has several advantages compared to DIY-input management such as 1) always correctly adapted to active locale and 2) behavior coherent with user settings (key repetitions per second etc).
For keyboard buttons, most of the time WM_KEYUP and WM_KEYDOWN work just fine... sometimes they get stuck when switching focus and such but I don't think that's a problem in general....[/quote]

I could go on forever dude. So I look forward to declare a day I will have taken this crusade for a decade. I want to thank all the people who actually also fight this apparently hopeless battle and all the people properly using the search button.

Um, I don't get this hopeless battle thing. As far as I remember, almost everyone got the WM_CHAR thing after explaining them. It's not one person who ask the same question again and again, but individual persons.

Dealing with input, character or key, is implementation detail after a point. I was implying that one cannot design everything up front, especially if one is an inexperienced newbie. One has to start the actual programming and solve problems when one meets them. What the OP does seems to be temporizing... (a'la "stupid over-preparedness ")

Actually, you CAN call C++ code just fine from WinProc; including allocating memory and the like. What you must not do is allow any thrown exceptions to propagate out of WinProc.

That is correct. I cut a few corners.

Um, I don't get this hopeless battle thing. As far as I remember, almost everyone got the WM_CHAR thing after explaining them. It's not one person who ask the same question again and again, but individual persons.

Do you use a QWERTY layout? I don't. You probably don't have a standard QWERTY either I suppose.
Do you have any form of impairment? I do. And I can guarantee that in 2011, finding that people - albeit individual people - don't bind actions by button is just sad. Sad. Sad.
So, as I have some real impairment which prevents me from using QWERTY for more than 2 hours/day without involving massive pain, excuse me if this touches my sensitivity triggering irrational behaviour. Because, from my point of view, the problem is so big it probably makes sense to escalate it to a top priority. Whatever it takes.
Your point of view is understood and your point is taken. I have misunderstood your words. Please accept my most sincere apologies.

First thing, I'm here to learn, noone born genius, even you. Also, I understood that pressing W keyboard button (for example) doesn't mean that on the screen I will see W, this is why I'm asking how could I split the WM_CHAR and WM_KEYDOWN messagesto handle them properly when I need to type in a chat and when I need only to handle input to move the player

Thank you very much, I will remember this...