Fixes#4447.
Fixes#4222.
The symptoms for these two issues are related: the language associations
change and keyboards stop functioning correctly. The issue is described
in detail in #4447.
Although this fix should be considered 'experimental', we should
probably include it in the release of 14.0, because it fixes a
longstanding issue with Keyman and Windows languages.
Fixes#4554.
The Online Update form did not have the correct owner window for some
operations, meaning that the elevation dialog would not get foreground.
If the registry setting `HKCU\Software\Keyman
Engine\Debug:Flag_UseAutoStartTask[REG_WORD]` is not `0`, then the this
will enable the restart task. Otherwise, all aspects of it are disabled.
For Keyman 14.0 initial release, we will have this flag disabled. If we
can improve stability of it, we'll consider turning it on.
Fixes#4467.
Background: in some scenarios, e.g. files in use, Setup must restart
before it completes. This is particularly the case if kmcomapi.dll is
locked and Windows will move the new version into place after a restart.
In this scenario, we would end up calling the old version of
kmcomapi.dll to install keyboards, etc, which is definitely not
desirable.
Problem: Setup was not saving complete state before the restart, so when
it resumed post-restart, would get a blank slate to work from, losing
command-line options passed in and any choices that the end user may
have made during the installation.
Fix: This PR adds serialization of the `TInstallInfo` state data, so
that the install state can be saved to disk before restart, and reloaded
after the restart. This also means that the `-c` parameter now takes a
filename, being the temporary state JSON file, and when in
"ContinueSetup" mode, no longer needs to perform all the checks it did
previously, making the second half of Setup somewhat faster.
Testing: Added a unit test for the serialization of `TInstallInfo`, and
have tested on a VM in various scenarios without problems.
This fix is somewhat broader than I really like to make while in Beta,
but I don't think there was a viable alternative.
Fixes#4490.
Fixes#4435.
There are three parts to this:
1. Ensure that transient language profiles associated with a disabled
keyboard are enumerated correctly
2. Stop trusting `LocaleNameToLCID` when it returns a transient language
id, as it sometimes reports out-of-date values. We don't need to
trust it in these cases anyway, because we have already collected the
relevant transient language data from Win8Languages.
3. Finally, setting the profile GUID to `GUID_NULL` is simply tidyup,
which does not have impact on the running code currently but makes
state consistent.
I believe that part 2 fixes#4435 because the symptoms are identical.
But as I am unable to repro that particular issue on my machine thus
far, that is an assumption. Hopefully we can get a good test result from
@MakaraSok.
Fixes#4619.
The hotkey check in keyman32 would ignore right modifier keys, but the
behaviour was not quite right: it actually needs to take the modifier
into account, but just not treat it as a valid modifier.
While fixing this, I noticed that some of the tests in the
`KeyLanguageSwitchPress` function were using the wrong modifier flags. I
wish I had fewer different modifier flag sets but that ship has probably
sailed.
Fixes#4558.
This makes a number of fixes to get the context help working correctly
in Keyman 14:
1. Adds support for `redirect:` header in help .md files so that we can
do redirects for the context content in Keyman for Windows help in the
lua filters.
2. Renames Keyman for Windows help files to .htm, because that's what
the .chm format is expecting, and what Delphi assumes for its .chm
integration, and thus splits the html and htm lua filters.
3. Renames and makes more consistent the various context help pages.
4. Adds redirects for all pages that have sufficient content on other
pages.
5. Fixes the instantiation of help in various Keyman for Windows forms.
6. Defaults to opening help from the Keyman source repo if the calling
app is running in the source repo (this is just a development-side
tweak that simplifies my life).
Fixes#4409.
If a user attempts to install an older version of Keyman, they need to
be able to choose to install the older version, and not the newer one
offered to them from online. However, the selector was hidden in the
Install Options dialog, even when it should have been accessible.
Fixes#4557.
When focus changes, we need to re-run `_PreserveAltKeys` as settings may
have changed, meaning we have to preserve a different set of keys. I
also made the `_PreserveAltKeys` function idempotent so that we don't
have to worry about cleanup before calling it -- by calling the cleanup
function internally instead.
Fixes#4591.
I fixed incxstr in 4 places:
1. Common/Core: kmx_xstring.cpp
2. Engine: xstring.cpp
3. Test project importkeyboard importkeyboard.cpp
4. Test project m-to-p m-to-p.cpp
I updated mcompile to remove its own copy of incxstr (identical to that
in xstring.cpp) to reduce WETness but opted not to do so for the test
apps, which are pretty much throwaway anyway.
I note that there is more work we could do here; we need to check every
character as we increment so we don't miss a `U+0000` end of string with
malformed data. But I would like to tackle that as a separate job at
some point in the future after Core integration.
I discovered this while working on #4586. The code in question was
updating `*puKey` and then trying to dereference the array on the basis
of its new value, which (a) would give the wrong result, and (b) could
be reading off the end of the array (although not crashing it seems),
e.g. for `"` -> `VK_QUOTE`, which has a value of `0xDE`.
I am guessing that the reason we have not seen any bug reports on this
is that the keystroke handler falls back to an alternate code path, so
in the vast majority of cases, keyboards would continue to work
correctly. Furthermore, the test was just for truthiness of the `BOOL`
so probably at least 50% of the time we'd have been okay anyway. Or
something. Anyway, I reckon this is better.
Fixes#2241.
The `&CasedKeys` system store is a compiler feature that reduces the
repetitive nature of keyboard rules for `CAPS` and `NCAPS`. The
`&CasedKeys` system store defines a list of virtual keys for which
'normal' Caps Lock rules apply. This store has no default value, for
backward compatibility.
Once this store is defined, then you can define just the unshifted and
shifted versions of a rule, and Keyman Developer will synthesize the
`CAPS` and `NCAPS` versions of the rule. For example, you may have the
following rules:
```
store(&CasedKeys) [K_A]
+ [K_A] > 'α'
+ [SHIFT K_A] > 'Α'
```
These would be replaced by the compiler with:
```
store(&CasedKeys) [K_A]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
You can also use this functionality with characters in the key part of
the rule:
```
store(&CasedKeys) 'a'..'c'
+ 'a' > 'α'
+ 'A' > 'Α'
```
and the compiled expansion would be similar:
```
store(&CasedKeys) [K_A] [K_B] [K_C]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
This feature is backwardly compatible with Keyman 6.0, as it is entirely
implemented in the compiler.
This feature is not compatible with mnemonic layouts, and the keys
defined in the `&CasedKeys` store must be the unshifted base keys as
found on a US English keyboard, or you can use ISO9995 identifiers if
you prefer.
If you define a rule where you specify either `NCAPS` or `CAPS`, for a
key found in the store, then no change will be made to that rule. You
can also continue to define rules which use `NCAPS` or `CAPS` for keys
not found in the store.
As a side-benefit, this allows the visual designer to be used and
support Caps Lock, although at this stage, the `&CasedKeys` store is not
surfaced in the visual designer.
Relates to #2241.
Range expansions are a new language feature that reduce verbosity in
Keyman Keyboard Language (.kmn) files by making it possible to collapse
sequential ranges with a new `..` operator. It is envisioned that these
will be used primarily in stores.
Two kinds of expansions are available: character ranges, and virtual key
ranges.
The syntax is:
```
char '..' char
vkey '..' vkey
```
Where the `char` terminator is a single normal character, and the `vkey`
terminator is a single virtual key. `outs` is permissible for
terminators but no other statement is allowed. Whitespace is per normal
Keyman keyboard language syntax.
Character ranges will replace the range with the set of characters
between the terminators, based on the Unicode value of the terminators.
Examples:
```
store(alphabet) 'a' .. 'z'
store(alpha_not_bq) 'ac'..'pr'..'z'
store(capitals) U+0041 .. U+005A
```
Virtual key ranges work in a similar fashion, but with virtual keys. The
starting and terminating virtual key must have the same shift state.
This will be most useful for character and numeric virtual keys, as the
ranges are based on the numeric value of the virtual key as defined by
Windows, not its position on the keyboard.
Examples:
```
store(alphakeys) [K_A] .. [K_Z]
store(numkeys) [K_0] .. [K_9]
```
Ranges must be positive, that is, you cannot use `'z' .. 'a'`.
While this expansion is not expected to be very useful in rules, it is
still permitted. `context()` and other offsets are calculated on the
expanded form, not the collapsed form. Similarly, `any()`/`index()`
offsets are calculated on the expanded form.
'a' .. 'z' > context(3) c this produces 'c', not 'z'
Because ranges are expanded at compile time, ranges that are overly
long will result in an error, so you cannot use, for example:
```
store(AllUnicode) U+0020 .. U+10FFFF
```
The precise maximum length of a range is dependent on the context where
it is used.
The changes are entirely compiler-based; no change is made to the .kmx
file format or to the Keyman apps.
Fixes#2789.
The Keyboard Fonts dialog skipped some fonts which it did not recognise
as valid TrueType fonts. As a bonus, I've rewritten a few parts of it to
make it significantly faster to load.
I also turned off the font formatting for the list, as it was not very
helpful and hurt performance considerably.
