Before the fix, most of the AltGr chars are swallowed or mistranslated.
Root cause — three separate bugs in Native.SendCharViaScanCode
-
Layout selection. The method iterates every installed layout
and uses the first one that can map the character. On systems
with multiple layouts (e.g. de-CH + US) this can pick a layout
different from the one the target window actually interprets
through. Fix: query the foreground window's active layout first,
fall through to other installed layouts only if the active one
can't produce the character, and fall back to KEYEVENTF_UNICODE
when nothing matches (skipping the Alt+numpad path, which doesn't
reach Linux/Mac VM guests).
-
AltGr simulation. AltGr combos were sent as LCtrl + LMENU.
Apps (Chrome, Office, VMware Remote Console, …) interpret a
synthetic LCtrl+Alt+<letter> as a keyboard shortcut and swallow
the combination. A physical AltGr keystroke does emit an LCtrl
scancode, but the OS flags it as "injected by the keyboard layout"
so apps distinguish it from a real Ctrl press. SendInput-generated
LCtrl has no such marker. Fix: send RMENU alone with
KEYEVENTF_EXTENDEDKEY and no explicit LCtrl — the same trick
AutoHotkey and xdotool use. Apps and VM consoles reliably
recognize this as AltGr.
-
Extended-key flag. SendKeyWithScanCode didn't support the
extended-key flag, so even if we'd wanted to send RAlt correctly
we couldn't. Added an optional extended parameter.
Fix
Branch with a single commit: https://github.com/thomasmebes/ClickPaste/tree/fix/altgr-and-deadkey-handling
Commit (full rationale in message): thomasmebes/ClickPaste@a5e983c
Touches only Native.cs, +86 / −33 lines.
Tested
Before the fix, most of the AltGr chars are swallowed or mistranslated.
Root cause — three separate bugs in
Native.SendCharViaScanCodeLayout selection. The method iterates every installed layout
and uses the first one that can map the character. On systems
with multiple layouts (e.g. de-CH + US) this can pick a layout
different from the one the target window actually interprets
through. Fix: query the foreground window's active layout first,
fall through to other installed layouts only if the active one
can't produce the character, and fall back to
KEYEVENTF_UNICODEwhen nothing matches (skipping the Alt+numpad path, which doesn't
reach Linux/Mac VM guests).
AltGr simulation. AltGr combos were sent as
LCtrl + LMENU.Apps (Chrome, Office, VMware Remote Console, …) interpret a
synthetic
LCtrl+Alt+<letter>as a keyboard shortcut and swallowthe combination. A physical AltGr keystroke does emit an LCtrl
scancode, but the OS flags it as "injected by the keyboard layout"
so apps distinguish it from a real Ctrl press. SendInput-generated
LCtrl has no such marker. Fix: send
RMENUalone withKEYEVENTF_EXTENDEDKEYand no explicit LCtrl — the same trickAutoHotkey and xdotool use. Apps and VM consoles reliably
recognize this as AltGr.
Extended-key flag.
SendKeyWithScanCodedidn't support theextended-key flag, so even if we'd wanted to send RAlt correctly
we couldn't. Added an optional
extendedparameter.Fix
Branch with a single commit: https://github.com/thomasmebes/ClickPaste/tree/fix/altgr-and-deadkey-handling
Commit (full rationale in message): thomasmebes/ClickPaste@a5e983c
Touches only
Native.cs, +86 / −33 lines.Tested