On Fri, 22 Feb 2002, Arjen Nienhuis wrote:
The problem with
152: ((LPBYTE)ptr)[i] = 0x80; 153: ((LPBYTE)ptr)[i | 0x80] = 0x80;
Yes, that is obviously wrong, but certainly not because of lack of DIK mapping. If the user presses UP, this code would set both the numpad UP (DIK_NUMPAD8, 0x48) and the gray UP (DIK_UP, 0xC8). The fact that this does cause a double keypress is another sign that it's all just scancodes (that MapVirtualKey handles)...
is that it breaks a program I have: It moves the cursor two positions on a key press. When I checked the MapVirtualKeyA( i, 1 ) results in windows, I noticed that it wasn't the direct mapping between VK and DIK.
True, it's a bit complicated, but your table doesn't improve that, you'd pretty much just duplicate MapVirtualKey's table.
I don't think this table is dependant on the keyboard layout. I think (VK_5 <=> DIK_5) is also true in german or french. The only buttons that might be a problem are:
{VK_OEM_1, DIK_SEMICOLON}, {VK_OEM_2, DIK_SLASH}, {VK_OEM_3, DIK_GRAVE}, {VK_OEM_4, DIK_LBRACKET}, {VK_OEM_5, DIK_BACKSLASH}, {VK_OEM_6, DIK_RBRACKET}, {VK_OEM_7, DIK_APOSTROPHE}
but I don't know if those are dependant on the keyboard layout. Do you?
I think they are.
I also found out that the Microsoft code for DirectInput doesn't use GetAsyncKeyState, as there is a bug in that function, and not in DI.
Yes, Microsoft does it differently than Wine, but in the name of clean DLL separation, the Microsoft way isn't currently possible in Wine. It should be possible to fix that, but it would take some effort.