DirectInput -> Keyboard -> GetDeviceState

Ove Kaaven ovehk at ping.uio.no
Fri Feb 22 12:34:32 CST 2002


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.





More information about the wine-devel mailing list