Fixes#4003.
This addresses the majority of locations where we use the name "Keyman
Desktop" in code. There will be some filenames and paths that do not
change at this point -- particularly at a source level. For now, the
focus is on the user interface changes.
While making these changes, I also made the VERSION and MANIFEST
resources more consistent.
We used the 'Started' event when testing Sentry integration. We no
longer need it, but I left it in as commented code so we can re-enable
if/when we do Sentry updates in the future and need to re-test.
Fixes#3993.
Fixes KEYMAN-WINDOWS-4P.
Handles network errors which caused an exception, e.g. connection timed
out, or 12030 The connection with the server was terminated abnormally.
Fixes#3563.
When a keyboard is updated in an online update check, keep the existing
language assocations. This is fixed by using the new install paradigm
which does not change the user's language associations, and so it also
happens to fix issues with non-elevated users who do an update and would
end up with no languages installed.
Fixes#3994.
Task creation was failing for some users because Windows Tasks are all
stored in a shared folder, so attempts to use the same task name by
different users were failing, especially if the user was a non-admin
user.
Furthermore, attempts to execute the trigger would fail because Windows
treats keyman.exe as needing elevation in this context (even though it
doesn't, actually), and so I changed the trigger to call `kmshell -s`,
which then does the needful.
Finally, the uninstaller now attempts to remove all the scheduled tasks
in the Keyman folder. It doesn't care if it fails -- it's just cleanup
and doesn't impact the system adversely if the tasks hang around.
In some circumstances, Sentry would get a range check error while
processing the call stack due to DWORD being defined as NativeInt,
not NativeUInt, in old JWA libraries. This would mask the original
exception, and could cause the app to hang.
Fixes#3863.
This adds the new `*RTLEnter*` and other tags introduced in #3851 to
the touch layout editor, and adds validation for use in 14.0 keyboards.
Due to a limitation in the compiler architecture, use of these tags
will not trigger the automatic keyboard versioning functionality; the
keyboard developer must explicitly specify `store(&VERSION) '14.0'`.
Also:
* synchronised error codes between .h and .pas.
* synchronised touch layout tags between Developer and KeymanWeb, and
cleaned up builder.js usage thereof.
* added support for KeymanwebOsk font override when special tags are
identified.
* added basic tests to ensure that the compiler is catching use of these
tags as needed.
* updated keymanweb-osk.ttf font in Developer.
Relates to #1635.
This goes with keymanapp/api.keyman.com#122, and ensures that major
upgrades are offered regardless of the rollout schedule, if they are
available, when the user manually checks for an update.
This replaces vectored exception handler code which fixed up the 8087 CW
with a thread-safe version of Set8087CW that avoids the global
variable Default8087CW. We would get occasional situations where
exceptions were raised on 2 threads simultaneously, which could lead to a
race where the first thread set Default8087CW to $1340, and then the second
thread would read that and think that is the default to keep. We want to
avoid touching Default8087CW altogether here.
See also https://stackoverflow.com/a/39684636/1836776 and RSP-13643.
Fixes#3832.
Removes the now-unneeded Internet Explorer dependency from Developer
Setup, and corresponding strings (plus a couple of other unused
strings).
I18n of these strings is a future project.
Fixes#3831.
This fixes both issues reported in the bug (dproj changes ensure
separate .tds, and Makefile changes fix order of execution so that
dbg is generated after sentryprep's cleanup).
The detection of the 102nd key is a heuristic - it will decide it is
present if it has a vk code and its corresponding unshifted character
is not the same as the backslash key. This matches the general pattern
for US vs European keyboards.
Fixes#3810.
Importing a Windows keyboard would not produce correct OSK for European
layouts because it was based on virtual key instead of scan code.
Mapping through the scan code back to "US" base layout resolves the
issue.
Note that there is a slight difference between Import Windows Keyboard
and Fill from Layout results, as deadkeys have slightly more information
in the Import process, and can display the base deadkey, whereas Fill
from Layout will result in a blank deadkey. This difference is by
design.
