mirror of
https://github.com/keymanapp/keyman.git
synced 2026-08-12 03:45:34 +00:00
fbcfd62678
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. |
||
|---|---|---|
| .. | ||
| UfrmOSKCharacterMap.dfm | ||
| UfrmOSKCharacterMap.pas | ||
| UfrmOSKEntryHelper.dfm | ||
| UfrmOSKEntryHelper.pas | ||
| UfrmOSKFontHelper.dfm | ||
| UfrmOSKFontHelper.pas | ||
| UfrmOSKOnScreenKeyboard.dfm | ||
| UfrmOSKOnScreenKeyboard.pas | ||
| UfrmOSKPlugInBase.dfm | ||
| UfrmOSKPlugInBase.pas | ||
| UfrmVisualKeyboard.dfm | ||
| UfrmVisualKeyboard.pas | ||