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.
Relates to #799.
Removes NRSIAllTags, alltags.txt, parser and utility units.
Also re-enables standardsdata.dpr unit test which needed some syntax
cleanup.
Fixes#1584.
In the "Select BCP 47 Tag" dialog, when the user starts typing a
language tag, e.g. "hi" for Hindi, the "h" would match "ha" for Hausa,
and set the script to "Latn". When the "i" was then typed, the script
box would not be cleared, giving an incorrect result of "hi-Latn"
instead of just plain "hi".
The earlier issue of "yo-Brai" has already been resolved.
This is part 1 of 2 of a fix for #917. This adds in version 14.0
targeting and a new function `KNO` which is used in one specific place:
when a context() statement references a notany() statement. This
minimizes any risk in this change because existing supported patterns
should compile identically.
If the compiler finds this pattern, it will enforce 14.0 minimum version
for web targets.
Fixes#3801.
Fixes#3802.
Fixes KEYMAN-WINDOWS-5M.
Fixes KEYMAN-WINDOWS-5N.
This is a two-part fix for Keyman Configuration where it appears there
was a race with creating a temporary file, and which caused a cascading
exception.
The first part resolves the race; the second part (in
UfrmInstallKeyboard.pas) adds a little extra robustness (probably not
totally necessary).
Fixes#3797.
Fixes KEYMAN-WINDOWS-5H.
Report unexpected errors creating or deleting scheduled task, and ignore
expected errors better, handling a potential race condition where two
processes both attempt to create a folder at the same time.
Note that creating the task should not be a race because we use the
`TASK_CREATE_OR_UPDATE` flag.
If the list of actions that Setup will perform is too long, a scrollbar
will now be shown. This will probably not arise frequently but certainly
helps if it does.
Fixes#3689.
When Setup is starting, it can sometimes take a few seconds to show the
main form because it is querying an online server and unzipping various
files. This shows a small progress bar window so that the user doesn't
wonder what is going on.
The progress bar is fairly basic: it has only 4 steps, and because all
actions are happening on the main thread, does not animate well or
smoothly. In my view, it is not worth redesigning into a multi-threaded
process for the sake of this progress bar dialog.
Relates to #3689.
