This makes it easier to track what is happening for errors where
otherwise we found that exception messages were being cropped; for
example, see KEYMAN-WINDOWS-X.
The error messages were being cropped because the exception handler was
in the exe module, but the exception was being raised in kmcomapi
module. When the exception was handled, the handler tested to see if
the exception object inherited from exemodule.Exception, but it was
inheriting from kmcomapi.Exception instead, and so it did not attempt
to load the message detail.
By adding `safecall` calling convention to `KeymanCustomisation`, we
move responsibility for handling the exception to the
`TKeymanAutoObject.SafeCallException` function, and we get full detail
for the exception.
Adds Sentry breadcrumbs for the following crash reports:
* KEYMAN-WINDOWS-62
* KEYMAN-WINDOWS-6H (? no reports in recent releases, so may be
resolved)
* KEYMAN-WINDOWS-7J
* KEYMAN-WINDOWS-4R
The source of these crashes is hard to pinpoint, so hoping that this
additional data sheds some light.
Fixes#7698.
Due to a `>` instead of a `>=` check, there was a one pixel high box at
the bottom of each list of input methods for each language which would
reuslt in an invalid value for `FNewHoverKeyboard`
(`lang.KeyboardCount`).
As well as fixing this, I changed the result for clicking below the
input method list to the more logical last item in the list rather than
the first.
Fixes#7690.
When kmshell.dpr is being shut down by Windows via `WM_ENDSESSION`, the
order of termination of units through `finalization` sections means that
`IdStackWindows` was finalizing while components were still depending on
it, causing a cascade of exceptions resulting eventually in the crash
visible in #7690.
We saw this when there were message loops before `Application.Run` had
ever been called. For example, message box/dialog, ShellExecute (yep...
this can do a `PeekMessage`), `THttpUploader` (which calls
`Application.ProcessMessages`) and probably others.
Ideally, it would be better to always call `Application.Run`, but it is
not safe to call `Application.Run` more than once, because it ends up
adding multiple `DoneApplication` exit procs, which would likely cause
other crashes.
I landed on the somewhat heavy-handed solution of adding
`IdStackWindows` to the start of the project `uses` list, ensuring it is
the last unit to be finalized -- importantly, before `Vcl.Forms`. A
better solution would be to find a way of ensuring that
`Application.Run` is called, just once, in all situations, but this is
likely to be hard to achieve. The shutdown sequence for Delphi apps is
so very, very fragile.
Relates to KEYMAN-WINDOWS-B.
While this doesn't address the root cause of the exception, it should
prevent this unhandled exception, and adds breadcrumbs to help us see
which code path might be triggering the issue.
