Worked around bogus key mapping on 95/98/me where multiple virtual
keys are mapped to the same button. For example, the backslash virtual key shares a button with some other virtual key on british english key mappings. Synergy could end up using the wrong virtual key. In the given case, the other virtual key produced no character at all. To determine which virtual key should really be mapped to a button we map the button back to a virtual key and see if it's the virtual key we started with. Also fixed mapping of pause key. Previously, windows+pause sent to a win32 client wouldn't bring up system properties like it should.
This commit is contained in:
parent
bac1f24a53
commit
b1ead05a3c
|
@ -1375,6 +1375,18 @@ CMSWindowsKeyState::mapVirtKeyToButton(UINT virtualKey,
|
||||||
|
|
||||||
default:
|
default:
|
||||||
button = (KeyButton)MapVirtualKey(virtualKey, 0);
|
button = (KeyButton)MapVirtualKey(virtualKey, 0);
|
||||||
|
|
||||||
|
// okay, now we have the scan code for the virtual key. windows
|
||||||
|
// may map different virtual keys to the same button. for example,
|
||||||
|
// windows 95/98/me maps virtual keys 220 and 226 to scan code 86
|
||||||
|
// in the british english keyboard map. why? who knows. it
|
||||||
|
// doesn't make any sense since a button can't actually generate
|
||||||
|
// more than one virtual key. to avoid this stupidity, we map the
|
||||||
|
// button back to a virtual key to see if it matches the starting
|
||||||
|
// point.
|
||||||
|
if (button == 0 || MapVirtualKey(button, 1) != virtualKey) {
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -1442,6 +1454,9 @@ CMSWindowsKeyState::mapVirtKeyToButton(UINT virtualKey,
|
||||||
case VK_DECIMAL:
|
case VK_DECIMAL:
|
||||||
break;
|
break;
|
||||||
|
|
||||||
|
case VK_PAUSE:
|
||||||
|
break;
|
||||||
|
|
||||||
default:
|
default:
|
||||||
button |= 0x100u;
|
button |= 0x100u;
|
||||||
extended = 0;
|
extended = 0;
|
||||||
|
|
Loading…
Reference in New Issue