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#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#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#4525.
This is a regression from #4468, which inadvertently added modifier
checks for `VK_CAPITAL` and `VK_NUMLOCK`, when it should not have done
so, as the flag was then being reset when the key was released rather
than toggled.
`ProcessModifierChange` pretended that it could handle `VK_CAPITAL` and
`VK_NUMLOCK` but it would never have worked, and the other caller (the
GetMessage hook) never passed those key events through, only Shift, Ctrl
and Alt, so that's now what the TIP handler does as well.
This leaves the rest of the fix from #4468 in place as that appears
correct.
I took the opportunity to move a repeated function declaration into
keyman64.h.
Fixes#4369.
When Keyman is not handling a particular virtual key, it does not
preserve the virtual key (TSF terminology, essentially reserves that
virtual key + modifier for Keyman). In this situation, Keyman still
receives and processes the virtual key event, but the modifier state
is not passed through by kmtip to keyman32. This is normally okay,
because our `GetMessage` hook is responsible for tracking modifiers.
However, in UWP apps, our `GetMessage` hook does not get run, and so
we lose the modifier keys. Thus, this update ensures that the modifier
keys are processed when received by the TSF TIP.
It does not hurt to process modifier events twice.
We should uninstall transient languages before disabling them
because once we have disabled them, we lose the language
association and cannot find the entry to uninstall. catch-22.
Ensures we get a canonical tag per langtags.json as far as we possibly
can. This is a breaking change for the compiler as tags which were
formerly regarded as canonical are no longer regarded that way. This
mostly relates to script subtag but a secondary bug meant that some
other tags would have lost data in the canonicalization process
(because we did a lookup based only on the language subtag previously,
which is a no-no).
See keymanapp/keyboards#1452 for related work.
Two changes here:
1. Only post the refresh message to the master controller, so that we
get a single refresh regardless of how many controllers are
registered.
2. When Keyman is restarted, the global RefreshTag is reset to 0, so we
need to do a `!=` comparison rather than a `<` comparison to ensure
that apps with an existing keyman32.dll/keyman64.dll in memory get
refresh notifications (as their local `RefreshTag_Process` will
likely already be greater than `0`).
Also a small additional debug statement.
Fixes#4192.
If Keyman is already running, and the user attempts to start Keyman
again, a balloon will be shown to direct the user to the right place on
the screen.
Note: this worked in earlier versions of Keyman but stopped working due
to name changes for windows in the app.
I have also added a new string for balloon that will need translation.
Fixes#4343.
This patch makes all language codes from the langtags.json dataset
visible through the Add Language dialog. This avoids situations where
an incomplete code such as "cmo" can result in an error (a script is
required for "cmo" as it is written in either Latn or Khmr).
Fixes#4337.
The Sinhala language installation mitigation needed the BCP 47 code as
well as the language code with the new language installation process.
Fixes#4336.
Removes the "Show Keyboard Usage Page" hotkey entry as it has no effect,
and cleans up Keyboard Usage and OSK Hint strings from all the current
locales.
Fixes#4289.
Some settings changes would not apply immediately for 64-bit apps, as
the refresh was not being processed until keymanx64 received focus (i.e.
never, as keymanx64 does not have a visible window!)
In order for the BK_SURROGATE and BK_DEADKEY flags to be matched with
the correct xstring elements in the context, we need to delete the
elements from the buffer in reverse order.
decxstr would previously assert if attempting to move before start of
string. This is undesirable behaviour as it should instead return NULL
to indicate that we've finished the string.
I also corretected a buffer underrun which would be possible if
malformed data was in the xstring.
I checked all uses of decxstr to ensure that the NULL return value is
being tested correctly.
Fixes#4196.
When deleting characters in a TSF-aware app, we must delete both halves
of a surrogate pair. This behaviour differs from legacy apps, where a
single backspace is usually sufficient to delete both characters.
Truly ancient apps that do not know about Unicode surrogate pairs are
not going to delete both halves with a single backspace event.
Fortunately, these are few and far between; we would handle them on a
case-by-case basis if support questions for them arise.
When we come to integrating Keyman Core into Keyman for Windows, there
will need to be some careful checking of surrogate pair support, as it
is likely that the handling will need to change.
Fixes#4264.
The Android strings.xml format that we now use with Keyman Desktop has a
number of escapes that must be supported in order for text strings to be
rendered correctly, including: @, ?, ', ". Furthermore, positional
parameters have a slightly different format which we should transform on
load.
This change includes a unit test androidstringtokeymanlocalestring.
Fixes#2690.
Fixes#3082.
In the debugger, key events such as Enter, Ctrl+C, Ctrl+V were being
swallowed by the debug engine if they did not have rules within the
keyboard. This change emits the key events so the debug memo can
process them normally.
Fixes#4184.
If a package had a keyboard with language metadata, it would not
load that language data correctly, which then meant it would not
apply the mitigation correctly either, leading to a double elevation
dialog as Keyman tried to fallback to primary language.
Fixes#1285.
If running Windows 10 19597 or later, the underlying issue has
been addressed, so disable the mitigation for new installs of
the keyboard. Does not attempt to change the language code if
the keyboard is already installed.
The keyboard profile and registration strategy was not taking into
account the mitigation for Win10 1803 (#1285) and this meant that the
Amharic, Tigrigna and Sinhala keyboards would not install correctly.
Fixes#4013.
This turned out to be a lot more complicated than I expected, mostly due
to limitations in the Windows Shell API with regard to multiple monitors
and per-monitor DPI awareness (which we don't yet do in Keyman -- a
task for another day). Some of the Shell API functions are also
re-entrant, which is dangerous, so I avoided using those.
We now popup the menu relative to the Keyman icon far more precisely
which gives a much nicer feel to the menu interaction.
This change has three fixes to improve the reliability of notifying
Keyman Engine of updates to settings or keyboard installs:
1. It removes the closure pattern of the refresh thread, because that
was closing on a variable on a different thread (`RefreshHandle`) and
that could cause races and/or exceptions in the case of early free.
What's more, the closure was actually unnecessary as the variable was
really only used by the refresh thread!
2. It moves responsibility for setting the refresh token to the calling
thread so that the caller can depend on the token being the one that
is actually sent, removing a race.
3. Most important, the refresh thread now flushes all messages in its
queue, as there may be multiple messages relating to the window
construction that need to be processed before the wm_keyman_refresh
message can be handled. This greatly improves the chance of the
notification actually being sent!
Another thought: we could also try refreshing every 125msec for 5
seconds after the first change is detected. It's a bit yuck perf-wise
but would probably be pretty transparent to the user.
In testing, this looks good. It means the changes appear as soon as
ready, without substantial delays or performance issues. Polling this
makes me feel a bit dirty, but I'll just take a shower and be okay.
As Keyman now monitors the Windows keyboard list from Control Panel, it
is no longer sufficient to refresh the toolbar only when a Keyman
keyboard is updated, as at that point Windows has not refreshed its own
language list in the registry. Instead, we need to monitor changes to
the relevant registry key and then refresh when those changes are
'complete'.
There is a problem: there does not appear to be a good way to monitor
for changes to Windows language settings. WM_SETTINGCHANGE is sent when
a language is added by the user in Settings, but the actual change
happens asynchronously, and we are not notified when the changes are
complete.
We also do not get notifications when languages are added via APIs.
Given the async nature of the language profile changes, this leads to
race conditions when we try to refresh the OSK toolbar. My preferred
solution currently is to monitor the relevant key in a separate thread,
and wait 1 second post-changes to actually do the refresh.
Fixes#4006.
This fixes the list error exception which was masking the actual cause
of #4006, which is already fixed by #4164.
Related issue #4119 is also fixed by #4164.
