Repository navigation
Conversation
…cursor The WH_MOUSE_LL/WH_KEYBOARD_LL hooks were installed from the WPF UI thread, so every mouse event on the system (including in-game movement) waited behind UI work such as WebView layout or a synchronous engine rebuild, and Windows can silently drop a hook that misses LowLevelHooksTimeout (hotkeys then stop until restart). - Install the hooks on an AboveNormal background thread with its own message loop; Stop posts WM_QUIT and the thread unhooks on exit. - Capture the cursor position in the hook (MSLLHOOKSTRUCT.pt for mouse, GetCursorPos for keyboard) and scan at that point instead of reading the cursor later on the thread pool. - HotkeySelector now marshals hook callbacks onto the renderer. Verified on a Release build: injected Shift key events reach the hook thread (debug log), shutdown joins it cleanly (exit 0), UI smoke passes. Claude-Session: https://claude.ai/code/session_01QFKiA2aswHyp8SnpraLxE2
|
Warning Review limit reachedEnable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Next included review available in 37 minutes. View limit details
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
WH_MOUSE_LL/WH_KEYBOARD_LLhooks were installed on the WPF UI thread. Low-level hooks run on the installing thread, so every system-wide mouse event (including in-game movement) waited behind UI work: WebView layout, the content-fit animation, a synchronous engine rebuild from a game-mode switch. That is a plausible source of the reported random hitches.LowLevelHooksTimeout; hotkeys then stop until restart, which users would describe as inconsistent scanning.What
UserActivityHelper.Startinstalls both hooks on an AboveNormal background thread with its own message loop (queue created before startup completes);Stop()postsWM_QUITand joins (2 s cap); the thread unhooks on exit. Startup failures still throw to the caller with the original rollback.KeyUpEventArgs/KeyDownEventArgscarryCursorPositioncaptured in the hook (MSLLHOOKSTRUCT.ptfor mouse,GetCursorPosfor keyboard);HotkeyManagerscans at that point.HotkeySelectormarshals hook callbacks onto the Blazor renderer (it mutated component state from the hook).Validation
LLKHF_INJECTED); app shut down cleanly (exit 0).dotnet test408/408;verify.ps1 -Mode Ui2/2; CodeRabbit: no findings.Not proven
hook.dispatchstage times in Log.txt before/after.https://claude.ai/code/session_01QFKiA2aswHyp8SnpraLxE2