DirectInput -> Keyboard -> GetDeviceState

[Ove Kaaven]

On Sun, 24 Feb 2002, Arjen Nienhuis wrote:

> > Well, better. I still think it might be better to make MapVirtualKey
> > handle codes above 0x80 itself, but I'm not sure.
> > 
> 
> I don't think so. That is like extending the Windows API for our own 
> use. Isn't that what Microsoft is hated for?

I see no reason that MapVirtualKey shouldn't handle extended scancodes,
even under Windows. In fact, seeing how basic this functionality is, it
would be incredibly stupid of Microsoft if they didn't, so I'm not going
to believe that they don't support this without proof.

> > By the way, the problems we have with MapVirtualKey not having an
> > one-to-one mapping might be solved by implementing map mode 3 (see
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/keybinpt_0hfd.asp).
> > 
> I don't know what mode 3 returns, as I have only win9x, but the only 
> difference in the documentation is "that distinguishes between left- and 
> right-hand keys". I can't imagine that solves anything.

Well, currently we have that both left and right shift, and left and right
ctrl, etc, maps to VK_SHIFT and VK_CONTROL, thus making them hard to
distinguish... would be better to map to VK_LSHIFT, VK_RSHIFT,
VK_LCONTROL, VK_RCONTROL, etc, which is what mode 3 does.

> > This probably depends on the Num Lock state, or it's a Wine bug. But
> > perhaps this might also be fixed if we used map mode 3?
> Argh! It does depend on the Num Lock state. So, it can check for the Num 
> Lock state, and use different VK_ values, or it should not use 
> GetAsyncKeyState at all.

Something like that.

> An other, minor problem is, that DIK_POWER & co. officialy have no VK at 
> all, so they also can not be seen with GetAsyncKeyState.

If X reports that these keys are on the keyboard, and they do not exist in
Wine's keyboard tables, then the Wine keyboard code would assign them to
some VK_OEM_* or other, and some scancode between 0x60 and 0x80. But they
should probably be entered into these tables to make it predictable...

> Isn't there an easy way to see what physical buttons are pressed?

Not both easily and portably.