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. Vitaliy.