Ove Kaaven wrote:
On Fri, 22 Feb 2002, Arjen Nienhuis wrote:
The MapVirtualKey in GetDeviceState is not "the way to do it". It does not map VK_?? to DIK_??. I don't know why it does work most of the time.
It works because DIK_* is (at least up to 0x53, as far as I can see) identical to the PC keyboard scancodes, and MapVirtualKey handles scancodes perfectly well. I really don't think this is a coincidence, I think this is so that Microsoft's DirectInput do *not* need the kind of mapping table you propose. If there's a problem with the scancode conversion, you should fix it in MapVirtualKey. I think you may want to keep in mind that the scancode tables in the keyboard code denote extended codes with e.g. 0x138 (0x100 + 0x38), while the DIK for that key is 0xB8 (0x80 + 0x38). Perhaps the keyboard scancode tables could be changed to be compatible with the DIK codes without losing any functionality.
The problem with
152: ((LPBYTE)ptr)[i] = 0x80; 153: ((LPBYTE)ptr)[i | 0x80] = 0x80;
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. Also notice, that to check if the DIK_NUMPAD5 key is pressed it is necesary to check both VK_CLEAR and VK_NUMPAD5.
Then that table would depend on the keyboard layout (country, language, etc). It should be enough to keep the keyboard layout table mess in *one* place in Wine (in the keyboard code, where MapVirtualKey resides), not two.
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 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.