Fixes#5004.
This cleans up the use of controller windows. A single window is now
given the responsibility of being the master controller, which receives
messages from Keyman32 and other components around UI activation, active
keyboard, etc.
The master controller is keyman.exe's `TApplication` window, which does
not get destroyed and recreated, unlike the main form window.
Any thread which has responsibility for Keyman UI (keyman.exe main
thread, keymanx64.exe main thread) is also registered as a controller
thread. A controller thread has special handling for interactions with
keyman32 around focus tracking.
Caveats:
* While keymanx64 does not have a visible window and thus probably does
not need to be registered as a controller thread, it doesn't really
hurt.
* Note that keymanx64 registers the 32-bit controller thread as well,
which again is probably unnecessary as the 64-bit process cannot
interact with the 32-bit thread.
* Keyman's main form still handles wm_keyman_control messages, as there
are a number of other components which post to that window (e.g. text
editor, com library visual keyboard interactions). Unlike the original
problem trigger, the reference handle is not stored long-term and so
there is unlikely to be a problem with main form window re-creation
causing an issue in these contexts.
There are several TODO items in this which I will address in follow-ups,
to reduce the scope of these changes.
I hope to cherry-pick this to stable-14.0, but will run for a while in
15.0 before doing so.
Two changes here:
1. Only post the refresh message to the master controller, so that we
get a single refresh regardless of how many controllers are
registered.
2. When Keyman is restarted, the global RefreshTag is reset to 0, so we
need to do a `!=` comparison rather than a `<` comparison to ensure
that apps with an existing keyman32.dll/keyman64.dll in memory get
refresh notifications (as their local `RefreshTag_Process` will
likely already be greater than `0`).
Also a small additional debug statement.
Fixes#4289.
Some settings changes would not apply immediately for 64-bit apps, as
the refresh was not being processed until keymanx64 received focus (i.e.
never, as keymanx64 does not have a visible window!)
When a keyboard is installed, Keyman will now only refresh its internal
state on a given thread when that thread receives focus and/or input,
rather than immediately. This will dramatically reduce the chatter
caused by Keyman Engine when a keyboard is installed or settings are
changed.
Fixes#4003.
This addresses the majority of locations where we use the name "Keyman
Desktop" in code. There will be some filenames and paths that do not
change at this point -- particularly at a source level. For now, the
focus is on the user interface changes.
While making these changes, I also made the VERSION and MANIFEST
resources more consistent.
Fixes#3650.
This removes the bad call to `FreeLibrary` that was still present in
a callee of `DllMain` in keyman32. The refactor moves responsibility for
loading TSF to the `SelectKeyboard` functions and gets rid of the
associated thread globals.
The `TSFINTERFACES` struct is of course a future candidate for a class.
In the process I removed a lot of cruft from keyman32.cpp which was
either obsolete, irrelevant or just plain wrong. None of which had
material impact on the running code.
Both the win32 and the win64 keyman engine libraries would receive a
refresh notification, and then they'd both broadcast the change. This
change limits the broadcast responsibility to the 32-bit engine.
When loading transient language profiles, RefreshKeyboards would reset
the list of profiles (and in so doing, also leak memory). Instead, the
list should be cleared before the initial language profile list load.
Keyman32/keyman64 were not reading the new 'Transient Language Profiles'
key which is needed with Keyman 14. Minor tweak to ensure we don't scan
through more profiles than necessary when activating tip in aiTIP.cpp also.
Fixes#2147.
This potentially addresses the issues reported in #2147 where Keyman
would crash due to a race condition as a critical section was not
deleted before attempting to recreate it.
Some logging has been added for debugging these issues.
Also fixes memory leaks and another race on startup relating to loading
the taskbar icon.
There are still some known memory leaks because DLL_THREAD_DETACH is
not called for all threads before keyman32.dll is unloaded, so those
threads don't get the opportunity to clean themsselves up. However, the
key danger with the csGlobals critical section has been addressed.
[Windows] More tidyup and robustness for metro app support - debug cleanup and serialization of input (not quite finished)
[windows] Refactor serialized input code when used with key event thread model
[windows] Add consistent precompiled headers for other projects
[windows] Merge console window test into metro support
[Windows] Tidy up work and identify additional TODOs for metro-style app support
[Windows] Ensure error case falls through to default hook processing for console windows
[Windows] Refactor shared memory into memory mapped file so we can cross 32-64 bit boundary
[Windows] Tweaks to C++ security calls and parameters
[Windows] Start refactor of SerialKeyEvent* classes
[Windows] Rename to SerialKeyEventServer (refactoring)
[Windows] Complete refactoring of SerialKeyEventClient class
[Windows] Further encapsulation and cleanup with 'interfaces' to reduce header pollution
[Windows] Complete serialization fix with move of modifier state management from client thread to server thread to guarantee consistency
[Windows] Replace atom-based keyboard switching with memory mapped file indexed to avoid security constraints
[Windows] Fixup Left Alt+Shift interaction with serializer
[Windows] Use Windows 8.1 SDK for test
