While it may be smarter to move to a different build system altogether,
it is also a *lot* more work. This was a fairly minor syntax refresh to
get nmake working with our existing Makefile system. This is now no
longer compatible with Borland make, so you will need to use `nmake` to
build.
The presence of NMAKE.md informs builds systems that nmake should be
used instead of make.
* Adds a taskbar icon to highlight to user when Keyman Core library is
in use, with a crummy core.ico. This visual feedback will be removed
in late beta.
* Renames the 'use common core' registry setting to match other flags
* Adds a System Setting to make the Keyman Core setting visible in
System Settings and kmconfig.
We no longer need to backup debug files as they are saved to the symbol
store during a release build. This reduces the amount of storage
required for a release build and should speed up the build also.
Also fixes the broken build where backup had not been updated for the
new consistent build paths.
Move to all projects using bin/ and obj/ for outputs, and
cleanup all Makefiles and project files accordingly. Remove
some obsolete projects along the way. Cleanup .gitignore
also.
Fixes#5196.
It is complicated to start a `UIAccess=true` process with
`CreateProcess`, so instead we'll use `ShellExecute`. This means passing
a PID instead of a process handle to keymanx64.
I took the opportunity to refactor slightly the main function in
keymanx64, as the failure modes were pretty WET.
Fixes#519.
I have removed these .cfg, .dof, and .bdsproj files from the primary
projects in the Windows source. There is some ambiguity as to whether
.cfg files are used by the command line compiler (I checked with procmon
and they *are* read by dcc32.exe), so we will need to make sure that
no adverse changes have been made by this. In theory at least, the
.dproj data trumps .cfg data -- and all the projects in question have
a .dproj file -- so this should be a safe cleanup.
I have opted not to touch the /buildutils, /ext, /support and
/test folders at this point.
Fixes#5004.
This cleans up the use of controller windows. A single window is now
given the responsibility of being the master controller, which receives
messages from Keyman32 and other components around UI activation, active
keyboard, etc.
The master controller is keyman.exe's `TApplication` window, which does
not get destroyed and recreated, unlike the main form window.
Any thread which has responsibility for Keyman UI (keyman.exe main
thread, keymanx64.exe main thread) is also registered as a controller
thread. A controller thread has special handling for interactions with
keyman32 around focus tracking.
Caveats:
* While keymanx64 does not have a visible window and thus probably does
not need to be registered as a controller thread, it doesn't really
hurt.
* Note that keymanx64 registers the 32-bit controller thread as well,
which again is probably unnecessary as the 64-bit process cannot
interact with the 32-bit thread.
* Keyman's main form still handles wm_keyman_control messages, as there
are a number of other components which post to that window (e.g. text
editor, com library visual keyboard interactions). Unlike the original
problem trigger, the reference handle is not stored long-term and so
there is unlikely to be a problem with main form window re-creation
causing an issue in these contexts.
There are several TODO items in this which I will address in follow-ups,
to reduce the scope of these changes.
I hope to cherry-pick this to stable-14.0, but will run for a while in
15.0 before doing so.
Fixes#4976.
Fixes KEYMAN-WINDOWS-2K.
Fixes KEYMAN-WINDOWS-3F.
Fixes KEYMAN-WINDOWS-5A.
Fixes KEYMAN-WINDOWS-3E.
This fix reworks keymanx64's lifecycle, moving responsibility for
process shutdown from keyman.exe to keymanx64.exe.
This eliminates the need for interprocess communication, and simplifies
the startup and shutdown of keymanx64.exe. Removing this means that we
can more safely handle situations where two instances of keymanx64 may
be started, as one of them will rapidly terminate when it discovers that
its parent process has disappeared.
Fixes#4874.
Opening product help from the tray menu would end up at a broken page.
Given the title of the link is "Help Contents", I have opted to open at
the help contents... (rather than the alternative of context/tray-menu).
Fixes#4751.
Fixes KEYMAN-WINDOWS-76.
Fixes KEYMAN-WINDOWS-79.
Fixes KEYMAN-WINDOWS-7B.
Fixes KEYMAN-WINDOWS-7E.
Fixes KEYMAN-WINDOWS-7F.
Fixes KEYMAN-WINDOWS-7K.
Fixes KEYMAN-WINDOWS-7N.
Fixes KEYMAN-WINDOWS-80.
This resolves an issue where the TLangSwitchRefreshWatcher thread would
terminate early on Win7 (as it had no work to do), and free itself, but
then the main form would reference it post-free. Responsibility for free
has been moved to the main form.
This would result in various exceptions as state is corrupted at this
point.
Some of our Sentry reports are difficult to track down. Adding user
interaction breadcrumbs to Keyman Configuration (to start with) may
simplify this. I may add more breadcrumbs to other projects now that
this is available.
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#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#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.
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#4011.
Fixes#4039.
Fixes#4121.
This change completes the immediate-change model for Keyman
Configuration, by refactoring the refresh of settings out of the render
phase and more appropriately splitting applying and refreshing. It adds
a new message flag for wm_keyman_refresh, KR_SETTINGS_CHANGED, which
uses a random token approach broadcast to all applications on the
desktop to ensure that the refresh is received and multiple
notifications for the same event can be appropriately coalesced.
Most of the files touched are stripping out the refresh flags from the
render phase.
There is one small bug resolved at the same time with the options
properties, which were not reset to default if they had been deleted
from the registry prior to a refresh (see utilkeymanoption.pas).
Fixes#4012.
If the menu previously was scrollable, then it would potentially show
items at the wrong offset because the offsets were not reset when the
menu popup was called if no scroll was needed.
