pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Siegfried Pammer	1b78c76215	Synchronize headless UI tests on idle and hit-tested clicks The headless UI tests synchronized with the application by pumping a fixed number of frames (39 loops of RunJobs/Delay across 19 files) and by pressing at a point computed once from a control's bounds. Both encode how fast the machine that wrote the test was: on the loaded Windows Debug CI agent the frame count comes up short and the point goes stale, which is the recurring timeout in the tree context-menu tests and the reason each such failure was repaired one test at a time. Waiters.WaitForIdleAsync replaces the frame loops. It observes the actual precondition - no dispatcher job queued at Background priority or above, no assembly still loading in the background sweep, a frame rendered - and requires it on two consecutive polls so a thread-pool continuation about to post back is caught as well. Window.ClickAsync replaces element-targeted MouseDown/MouseUp pairs. It re-resolves the target on every poll and presses only once the window's hit test at the click point answers with that target, reporting the point and what was hit instead on timeout. That diagnostic exposed one vacuous test: User_Click_On_Visible_Row_Does_Not_Recentre_Viewport clicked the centre of a row wider than the tree viewport, which lies under the decompiler text view, so its assertion held without the row ever being clicked. It now clamps the point to the viewport like the other tree-row clicks. Clicks at text positions and press-only gutter clicks stay raw; they do not target an element. Assisted-by: Claude:claude-fable-5:Claude Code	2 weeks ago
Christoph Wille	0c287f5cde	Stabilize the bookmark-highlight tests against dispatcher stalls The bookmark navigation tests asserted the one-shot line highlight by polling the text view's renderer collection, but the adorner self-dismisses after an ~800 ms lifetime driven by a DispatcherTimer. On a loaded CI runner (the desktop job runs the UI and decompiler test suites concurrently) the dispatcher can stall long enough that the adorner registers and is dismissed again before the test's next predicate check, so the wait misses the entire play and burns its full 60 s timeout; raising the timeout cannot help with that. Record the last played line on DecompilerTextView as persistent evidence of the one-shot highlight and assert that instead - it also pins the highlight to the expected line, which the presence check never did. Assisted-by: Claude:claude-fable-5:Claude Code	1 month ago
Siegfried Pammer	a9d0d1573a	Scroll bookmark navigation to the re-anchored line, not the saved offset After scrolling to a navigated bookmark, the deferred apply restored the caret/scroll captured when the bookmark was created, which overwrote the centering that had just been computed for the resolved line. A bookmark re-anchors by token / IL offset, so a decompiler-setting change that reflows the C# moves it to a different line than the one saved in its view state; the stale offset then scrolled that line back off-screen, leaving only the highlight playing where it could not be seen. Restore just the captured foldings now -- and before centering, since collapsing or expanding shifts where lines sit -- and let the centered, re-resolved line be the final caret and scroll position. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago
Siegfried Pammer	cabe7bf458	Position bookmark navigation from non-decompiler active content Activating a bookmark only positioned the view when a decompiler tab was already the active content: the pending bookmark was set on DockWorkspace.ActiveDecompilerTab, which is null while a metadata table, the Options page, or the About page is showing. Navigating from there selected and decompiled the node but opened at the top with no line highlight. The pending bookmark now travels to the decompiler model that ShowSelectedNode routes the selection to, and is consumed in the document-apply step alongside the view-state restore -- mirroring PendingViewState -- rather than reacting to a property change. The earlier property-change path fired synchronously during selection, scrolled, then a deferred document apply reset the caret to the top with nothing left to re-apply. For a node that is already decompiled (re-shown after an interlude, where no apply step runs) a ScrollToBookmark callback on the model scrolls the live view directly, mirroring NavigateBookmarkInFile. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago