Fixes#5166.
This introduces versioned management of sentry.dll for Keyman for
Windows, Keyman Engine and Keyman Developer. As sentry.dll's ABI is not
backwardly compatible, we have to maintain independent copies of each
DLL for each app.
sentry.dll (or sentry.x64.dll for x64 apps) will be found in the
sentry-0.4.9 folder relative to the running process, except when running
from within the keyman repo tree (based on presence of KEYMAN_ROOT env
var). In those cases, the windows/src/ext/sentry sentry.dll will be
used, allowing us to test new debug time sentry DLLs easily.
A little bit of cleanup and consolidation was also done in the
KeymanPaths.pas unit.
When working on a new build script, I tripped over the `-?` question
mark help parameter here, as it needs to be escaped. Opted to fix all
the instances in our scripts, although AFAICT there would not have been
current bugs arising from this, as there were no conflicting one
character options lower in the case list.
Fixes#4607.
The Sentry 0.4.9 update actually simplifies some things. It does only
build with VS2019 by default, which pushed me to update Keyman build to
the same version, but that's a good thing overall, and was fairly
painless anyway.
Previously, we had our own custom build of sentry-native to make sure
that the C++ runtime libraries were statically linked to sentry.dll, but
this is now configurable in the build options, so we were able to
abandon our fork of the project at
https://github.com/keymanapp/sentry-native, which is good news. (I will
leave the fork there just in case but we'll eventually delete it once we
are convinced that this is robust.)
I have updated sentry.pas to match sentry.h; most of the changes are in
comments but there are a handful of new functions and some small changes
to function signatures.
I retested the Sentry exception scenarios and results can be found at
https://docs.google.com/spreadsheets/d/19xfurbn4cGubSCD68EGuKhcR5HrjaUcY/edit#gid=170604584
There may be an issue with Delphi x64 programs missing symbols from my
machine; something to keep an eye on but not a blocker for this merging,
I think.
Fixes#519.
I have removed these .cfg, .dof, and .bdsproj files from the primary
projects in the Windows source. There is some ambiguity as to whether
.cfg files are used by the command line compiler (I checked with procmon
and they *are* read by dcc32.exe), so we will need to make sure that
no adverse changes have been made by this. In theory at least, the
.dproj data trumps .cfg data -- and all the projects in question have
a .dproj file -- so this should be a safe cleanup.
I have opted not to touch the /buildutils, /ext, /support and
/test folders at this point.
Updates Chromium Embedded Framework to 89.0.18. Goes with
branch v89.0.18 of https://github.com/keymanapp/CEF4Delphi_Binary
Adds a script to checkout the correct version of CEF from the repo
according to CEF_VERSION.md.
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.
Fixes#4807.
We want to differentiate between a short copyright message and a
longer one that also contains a date. The long one is only needed in
one place in a typical keyboard project. This reduces maintenance when
making keyboard updates.
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.
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.
UFixupMissingFile referred to an old MSI component code, which meant
that it would never actually fix the installation. This now refers to a
current component code.
I may backport this to stable-14.0 but would like to assess its
stability over time first.
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#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#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`.
