When a European layout is active, and the user presses AltGr, Windows
generates a simulated VK_LCONTROL event alongside the VK_RMENU event.
This was causing the OSK to show LCtrl as depressed alongside RAlt, so
the OSK would show the wrong modifier layer, which was unhelpful and
confusing to the end user.
It is possible to detect the simulated VK_LCONTROL in the WH_KEYBOARD_LL
hook, because the scan code generated is 0x21D, instead of 0x1D.
Warning: this is not a documented value. (But, this 0x21D scan code is
not passed to the WM_KEYDOWN event!) Therefore, we use Keyman's existing
kmnLowLevelKeyboardProc to pass modifier key events on to the visual
keyboard.
This patch handles only this specific scenario, by watching for that
specific scan code in the new handler in the UfrmOSKOnScreenKeyboard
module, together with some minor refactoring so that it fits neatly.
A future improvement would be to have all modifier key processing go
through this new handler, and eliminate the timer-based polling of the
keyboard. However, there is some additional risk around missing events,
leading to 'stuck modifiers'.
Fixes: #14890
Build-bot: skip release:windows
This is a bit of an omnibus commit, apologies for that. This commit
moves Keyman Developer to a proper multi-process model, where editing
files from multiple projects is handled much more cleanly, with each
project loaded in a separate process.
Files that are edited outside of a project structure are loaded into a
'temporary project' in a single process, which provides a pathway for
existing users who may have legacy files outside the normal Keyman
Developer project model.
There are several components to this:
1. Inter-process communication (Multiprocess, CopyDataHelper units and
multiprocess test project). These modules establish a method of
enumerating running Keyman Developer instances (with EnumWindow),
recording relevant metadata for each instance (by thread id) in the
registry (registry used because it manages contention without
additional effort from us), and communicating between processes with
WM_COPYDATA.
2. Command-line parsing (TikeCommandLine). Determines project ownership
(ProjectOwningFile) for each filename passed on the command-line, and
passes these over to existing instances of Keyman Developer that have
that project loaded, or starts new instances as needed.
3. Temporary project management. Mostly in ProjectUI.
Also, moved GlobalProjectStateWnd management out of ProjectFile.pas and
into Project.pas, alongside other global project variables.
A follow-up will add functionality to determine if a file opened within
the Keyman Developer UI should open in the same instance or in a
separate instance (see TfrmKeymanDeveloper.OpenFileInProject). This will
use the same methodology as TikeCommandLine does now, so may involve
further refactoring.
This commit establishes the idea of 'keyman.kpj' as a future default
filename for Keyman Developer projects, but does not enable it, in
ProjectOwningFile. It is planned to introduce this fixed filename in
version 18.0 (see #10113).
