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.
Where more than one source of a file is available, e.g. a local
keymandesktop.msi which is older than the current published version
online, then Setup will choose the newer, online version by default,
but allows the user to change the install source in the Options dialog
to have an offline setup if they prefer.
This means that the 'best' location is now chosen at startup, and then
the user can override that.
Relates to #3689.
There were a number of obsolete values in setup.inf, and removing those
led to a small cascade of changes:
1. `MSIOptions` and `Version` properties were removed.
2. `Version` is now read directly from the .msi if it is present.
3. Package name and version are now read directly from local .kmp files,
rather than relying on metadata in setup.inf.
4. Setup now only loads .kmp files that are referenced in setup.inf, to
avoid scenarios where a user downloads the installer into a common
location that already includes .kmp files and is then confused by
why it is offering to install those files as well.
5. `Strings` property is not used outside of `TInstallInfo`.
Fixes#3650.
This removes the bad call to `FreeLibrary` that was still present in
a callee of `DllMain` in keyman32. The refactor moves responsibility for
loading TSF to the `SelectKeyboard` functions and gets rid of the
associated thread globals.
The `TSFINTERFACES` struct is of course a future candidate for a class.
In the process I removed a lot of cruft from keyman32.cpp which was
either obsolete, irrelevant or just plain wrong. None of which had
material impact on the running code.
1. Remove unused variables
2. Remove invalid build configurations
3. Move hotkey checks before touch keyboard panel check, so hotkeys
still work when touch panel is active; the touch keyboard panel check
is there to disable serialised input which conflicts with it.
Fixes#3562.
Second part of the two-part special with #3772. When Keyman
Configuration starts, it creates a task that is launched whenever a
specific Keyman event with id 256 is added to the Event Log. This task
launches keyman.exe to start Keyman (and if Keyman is already running,
the newly launched process will exit with no side effects).
This feature is behind a new feature flag `Flag_UseAutoStartTask`, so it
can be disabled in the event of compatibility issues.
The task is created or updated on each launch of Keyman Configuration
(or Keyman via the 'Keyman' shortcut in the Start Menu), and is
intended to be self-maintaining.
The test_starttask project (4 of the 12 files) is just a wrapper around
the start TKeymanStartTask class to allow for manual testing. No unit
tests for this at this time; I think it would be difficult to unit test
this effectively.
This is the first half of a two-part update to Keyman for Windows. There
are two significant changes here. These changes apply to
keyman32/keyman64, as well as kmtip/kmtip64, but will refer to the
32-bit equivalents for simplicity:
1. Instead of using `GetProcAddress` to connect to keyman32.dll, we
now have an import library connection. This removes one particularly
suspect piece of architecture for Keyman, as using `GetProcAddress`
could lead to a race condition, where keyman32.dll is unloaded after
that function is called but before we use the handle. This makes the
kmtip.dll build dependent on keyman32.dll; loading kmtip.dll (by
selecting a Keyman input method) also loads keyman32.dll.
2. It's not enough (yet) to load kmtip.dll. We also need to be running
keyman.exe itself, due to global hooks that we still require (it may
be possible, one day, to avoid these, but it doesn't look very
hopeful). To that end, kmtip calls new function `TIPIsKeymanRunning`
to check whether keyman32.dll is initialised (and hence keyman.exe
has initialised it). Then, if keyman.exe is not running, it issues an
event to the Windows Event Log, which we will pick up with a
scheduled task in the next PR.
The first part of this is an architectural change which may lead to some
change in behaviours, as keyman32.dll now may not be unloaded from a
process when keyman.exe exits, due to the lock that kmtip.dll now has on
it. It will be important to test this (@MakaraSok) by running through
various startup and shutdown scenarios. In my initial testing, I found
that there were some situations after restarting keyman.exe where I
needed to switch in and out of the Keyman TIP, but those were not all
critical.
This change also lays groundwork for an eventual ability to run the
Keyman input method without keyman.exe running, which will be helpful
e.g. on login screen, even if missing certain additional functionality
such as the serialised input queue.
As some of config state was cached, it would not refresh correctly
when displaying. This ensures that the config renderer uses its
own new instance of the COM API data on every refresh.
