On Windows 7, we will no longer attempt to canonicalize BCP 47 tags in
the same was as on later OS versions, because there appear to be some
significant differences in how they work, for example, zh-CN is not
converted to zh-Hans-CN on Windows 7, whereas it is on Windows 10.
This commit also refreshes the `KLog` unit which is useful for debugging
these types of scenarios.
Fixes#5091.
If the user has a default language that is not a minimal BCP47 tag, such
as `zh-Hans-CN` vs `zh-CN`, or if the default language does not have a
mapping in our `TLanguageCodeUtils.TranslateWindowsLanguagesToBCP47`
function, then kmshell would crash on install of a keyboard that had no
language metadata specified (i.e. neither legacy metadata in .kmx nor
modern metadata in .kmp).
This crash arose because the elevated instance of kmshell would install
a local-machine reference to `zh-CN` (as it back-translated from a
LangID), but the current user install would look for `zh-Hans-CN`, read
from the Windows registry `HKCU\Control Panel\International\User Profile`.
To further complicate matters, it is possible for the current user to
have a different default language than the elevated user on the machine.
Keyman was assuming that the default language was the same in both
cases.
This fix passes in the current user's default BCP47 and LangID to the
elevated portion of the keyboard install, so we can guarantee that
keyboard install which needs to use the default language, actually
installs for the current user's actual language code, and not a
canonicalized version (or a totally different code in the case of
elevation to an alternate admin user account).
Fixes#5683.
If `store(&name)` is missing from a keyboard, then fallback to the
filename of the keyboard (sans extension). This fixes a regression in
14.0 keyboard registration.
I opted not to make this change in kmxfile but rather in places which
use it in the Keyman Engine COM API, because I wanted kmxfile to remain
truthful about all details of what it is reading from the file.
Given that the COM API will now never return an empty string for the
name of the keyboard, there are mitigations for this in Keyman
Configuration which are unnecessary, but it is not harmful for them to
remain there.
Will cherry-pick to stable-14.0.
Fixes#5577.
This ensures that the touch layout file is marked as modified after
running Import From Layout in Keyman Developer, so that changes are
not lost when you save.
Font scaling on individual keys would ignore the vertical axis if the
horizontal axis reached the key width threshold, rather than calculating
the minimum of the two axes. This lead to weird effects, such as adding
characters to a key could make the font larger rather than smaller!
Reported by @jmdurdin.
Cherry-pick from #5298.
kmconvert built-in help was missing `-targets`, and the parameter
checking was skipping the last parameter (which only mattered if the
last parameter was `-nologo`, but still...).
Fixes#5245.
Interfaces should remain stable between versions of Keyman, so that an
upgraded kmcomapi.dll or keyman32.dll will not crash older clients, even
if they may not behave entirely as expected.
Fixes#5196.
It is complicated to start a `UIAccess=true` process with
`CreateProcess`, so instead we'll use `ShellExecute`. This means passing
a PID instead of a process handle to keymanx64.
I took the opportunity to refactor slightly the main function in
keymanx64, as the failure modes were pretty WET.
The `KMC_CHANGEUISTATE` flag for `wm_keyman_control` is no longer
processed anywhere. Removes it and the `UpdateKeymanUI` function which
called it.
The `#define` for the flag has been left, commented out, to clarify what
would otherwise be a gap in identifiers (use `git blame` to learn more).
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.
Fixes#4976.
Fixes KEYMAN-WINDOWS-2K.
Fixes KEYMAN-WINDOWS-3F.
Fixes KEYMAN-WINDOWS-5A.
Fixes KEYMAN-WINDOWS-3E.
This fix reworks keymanx64's lifecycle, moving responsibility for
process shutdown from keyman.exe to keymanx64.exe.
This eliminates the need for interprocess communication, and simplifies
the startup and shutdown of keymanx64.exe. Removing this means that we
can more safely handle situations where two instances of keymanx64 may
be started, as one of them will rapidly terminate when it discovers that
its parent process has disappeared.
Fixes#4988.
Fixes KEYMAN-WINDOWS-3F.
This relates to #4976 and is a stop-gap until we implement that. It will
reduce the number of reported errors (both to us and the end user) but
does not address the core issue, which requires a more significant
refactor.
Fixes#5216.
A `<text>` element in the regression text xml which contained only
whitespace would cause the import to crash as this would be ignored by
the XML parser, leading to a `Null` `nodeValue` for that element. To
solve this, we need to:
1. Use `xml:space="preserve"` attribute on `<text>` elements
2. Update the DTD to allow `xml:space` on `<text>` elements
3. While we are at it, move the DTD from `www.tavultesoft.com` to
`api.keyman.com`.
See also:
* keymanapp/tavultesoft.com#4
* keymanapp/api.keyman.com#155
Matches work completed in #5169 for Keyman Core, kmx_file.cpp.
While this code will hopefully disappear in 15.0, it's good to make sure
we aren't diverging beforehand.
Also tidies up a couple of other cases in `CopyKeyboard` in Keyman Core.
(cherry picked from commit c9897bb38f)
Fixes#5095.
If the text editor was loaded, `SetText` would not be synchronous
because it executed some Javascript to make the text change, so setting
the text and immediately reading it again would give the old text. This
is what the On Screen Keyboard editor was doing (it would synchronize
the visual editor and text editor at save). This fix updates `SetText`
to update the backing store as well as the front end editor.
