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/keybi...).
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.