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.
A few fixes and improvements:
* kmconvert was missing a command line parameter for `-target` to
specify the platform targets for a project
* kmconvert should avoid throwing unhandled exceptions, rather if
sentry is not present then just write to console.
* Include kmconvert and its data files in the deployment of kmcomp.zip,
which is done on the build agent (just need to make sure files are
in the right place here.)
* Side fix: also made sure kmcomp would emit the exception message to
console if sentry is not present.
Fixes#4965.
When speech recognition is enabled, it sometimes activates after a
Keyman keyboard is selected. This would cause Keyman to think it is
being deactivated. We needed to check in
`CKMTipTextService::OnActivated` that it was a keyboard-type TIP that
was being activated, and only deactivate the Keyman hooks in that
situation.
This commit also adds a little logging helper function, and removes an
unused variable `guidActiveProfile`.
Relates to #4700.
This simply adds some debug logging so that when the current crash
occurs, we can discover which windows have failed to automatically
close, which should give us enough detail to be able to reproduce the
problem, hopefully, and fix it.
Fixes#4939.
Fixes KEYMAN-WINDOWS-70.
Fixes KEYMAN-WINDOWS-71.
Fixes KEYMAN-WINDOWS-BR.
Fixes KEYMAN-WINDOWS-6J.
I am speculating a little here, because the root cause is not visible in
the crash report, but it appears that if keyman32.dll is renamed, that
the UnregisterControllerWindows function attempts to reload keyman32.dll
which means that (a) it no longer has a list of registered controllers,
and (b) it may fail to reload.
Instead of throwing an exception, we now only log this error in
development mode. The error is not likely to cause significant trouble
for end users as they are shutting down Keyman anyway at this point.
The resolution if there is any uncertainty during an upgrade is to
restart Windows. This is less than ideal but avoids file locks and
problems with in-memory DLLs. (Future versions of Keyman will schedule
upgrades to happen automatically after a restart before Keyman has been
started, in an effort to avoid this kind of trauma.)
