Doing tests with shift show that the presence of the shift key does not affect MapVirtualKey so SHIFT+2 still returns '2' since it is scancode based i doubt that numlock would either. So I do not think we need to worry about that.
-aric
Vitaliy Margolen wrote:
Aric Stewart wrote:
It is mapped with the keyboard mapping to the resulting character. so the key 'A' is DIK_A nomatter what its scancode or vkey would be. This is relevent to Japanese keymapping where the '@' key is in the '[' location the scancode for both is 0x22 but dinput generates DIK_AT in japanese and DIK_LBRACKET in us_qwerty
reworked to remove the giant case statement and hopefully be more clear. remove japan specific stuff as with the proper keyboard scancodes it works out.
I'm still not clear why do you need to translate the v_key into char? This involves a round trip to the X server for each key press.
Besides this will depend on the state of the num-lock, shift, etc. Which should not be the case for dinput. It should always return the same code for the key regardless of anything else.
Vitaliy.