This is a rudimentary start to having unit tests for keyman32.
At present, it will build only in win32/debug and requires you
to manually run make -DDEBUG beforehand. The tests currently
run in Visual Studio and are not integrated.
kmconvert built-in help was missing `-targets`, misspelled
`-full-copyright`, 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#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
Fixes#5195.
Fixes KEYMAN-WINDOWS-M0.
The splash screen for Keyman would crash on start with the latest
Chromium update. This fix resolves the issue, which related to the
resize-to-content code, by removing the resize-to-content code and
instead hardcoding the window size in the .dfm.
This is a significant simplification of the browser host and I think it
is worthwhile. The only place the resizing code was still used was in
the splash screen.
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.
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.
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.
