dinput: the DIK_ keycode is not the same as the scancode.

[Aric Stewart]

Thanks, I will look into what i can do. I worried about using VK codes 
because sometimes the same VK can produce different characters.  The 
specific example I am looking at is VK_OEM_3 which produces the '@' in 
Japanese and often the '`' character in other layouts.  I could use VK 
from the hook but i dont remember why i decided not to do that, but i am 
very sleepy right now, if that is better, and probably this should be 
extended to include VK codes for non ascii characters in case they do 
not line up either.  But it was a first pass.

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
>>
> 
> Looks good but have few comments:
> 
>> +static int map_dik_code(DWORD scanCode)
>> +{
>> +    DWORD vk = MapVirtualKeyA(scanCode,MAPVK_VSC_TO_VK);
> There is a vkCode in the KBDLLHOOKSTRUCT struct. You should use that instead 
> of doing the remapping all the time.
> 
>> +    CHAR c = MapVirtualKeyA(vk,MAPVK_VK_TO_CHAR);
>> +
>> +    switch (c & 0xFF)
>> +    {
>> +        case 32: return DIK_SPACE;
>> +        case 39: return DIK_APOSTROPHE;
> 
> Magic numbers are always bad. It's better to use vk_code here instead of a char.

see above.. though i could use the actual characters ' ' or 'A' for 
example. that may make it more readable.

I will look again tomorrow (I am on Japan time so it is way past bedtime 
for me tonight) but any other comments would be welcome.

-aric