Fixes#5683.
If `store(&name)` is missing from a keyboard, then fallback to the
filename of the keyboard (sans extension). This fixes a regression in
14.0 keyboard registration.
I opted not to make this change in kmxfile but rather in places which
use it in the Keyman Engine COM API, because I wanted kmxfile to remain
truthful about all details of what it is reading from the file.
Given that the COM API will now never return an empty string for the
name of the keyboard, there are mitigations for this in Keyman
Configuration which are unnecessary, but it is not harmful for them to
remain there.
Will cherry-pick to stable-14.0.
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.
This is a rudimentary start to having unit tests for keyman32.
At present, it will build only in win32/debug and requires you
to manually run make -DDEBUG beforehand. The tests currently
run in Visual Studio and are not integrated.
Fixes#5245.
Interfaces should remain stable between versions of Keyman, so that an
upgraded kmcomapi.dll or keyman32.dll will not crash older clients, even
if they may not behave entirely as expected.
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.
Matches work completed in #5169 for Keyman Core, kmx_file.cpp.
While this code will hopefully disappear in 15.0, it's good to make sure
we aren't diverging beforehand.
Also tidies up a couple of other cases in `CopyKeyboard` in Keyman Core.
Fixes#5166.
This introduces versioned management of sentry.dll for Keyman for
Windows, Keyman Engine and Keyman Developer. As sentry.dll's ABI is not
backwardly compatible, we have to maintain independent copies of each
DLL for each app.
sentry.dll (or sentry.x64.dll for x64 apps) will be found in the
sentry-0.4.9 folder relative to the running process, except when running
from within the keyman repo tree (based on presence of KEYMAN_ROOT env
var). In those cases, the windows/src/ext/sentry sentry.dll will be
used, allowing us to test new debug time sentry DLLs easily.
A little bit of cleanup and consolidation was also done in the
KeymanPaths.pas unit.
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.
The `KMC_CHANGEUISTATE` flag for `wm_keyman_control` is no longer
processed anywhere. Removes it and the `UpdateKeymanUI` function which
called it.
The `#define` for the flag has been left, commented out, to clarify what
would otherwise be a gap in identifiers (use `git blame` to learn more).
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.
