Fixed issue #983: Vertical scroll bar cannot reach the bottom when the widest node scrolls out of view - #1391
Open
TetzkatLipHoka wants to merge 1 commit into
Conversation
…ttom when the widest node scrolls out of view Without columns the horizontal scroll range is computed from the currently visible nodes only (GetMaxRightExtend). When the only over-wide node scrolls out of view at the top, the range shrinks, the horizontal scroll bar disappears, and the now taller client area clamps the vertical offset back up - which scrolls the wide node into view again and brings the scroll bar back. There is no consistent state that shows the last node: with the bar the tree may scroll to the bottom, but doing so removes the bar's reason to exist; without the bar the allowed scroll range ends where the wide node becomes visible again. The tree oscillates and settles at a fixed point where the user can never reach the bottom (measured: stuck at OffsetY -5 of -22, the last node stays clipped). Break the cycle by making the horizontal range grow-only while the scroll bar update is caused by scrolling itself (offset changes and SB_ENDSCROLL): the bar then simply stays until a trigger arrives that legitimately recomputes the range from scratch - resizing, structure or content changes behave exactly as before. Measured with a live window: line-scrolling now reaches OffsetY -22 with the last node fully visible, SB_ENDSCROLL keeps the position, enlarging the window still drops the bar, and scrolling back to the top shows it again. New regression test Tests/VTScrollRangeIssue983Tests.pas covers the symptom and both halves of the contract; without the fix the symptom test fails. Test suite: 2 pre-existing failures (TestCopyHTML1/2, also failing on unmodified master), no new failures. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Fixes #983
As analyzed in this comment: without columns, the horizontal range is computed from the visible nodes only. When the single widest node scrolls out of view, the range shrinks, the horizontal scroll bar disappears, the client area grows, and the vertical offset gets clamped back up - which makes the wide node visible again and brings the scroll bar back. There is no consistent end state that shows the last node, so the tree oscillates and the vertical scroll bar can never reach the bottom.
Any fix is therefore a semantics choice. This PR implements the least invasive one: while scrolling (
DoSetOffsetXYwith a vertical delta, andWMVScroll/SB_ENDSCROLL), the horizontal range may only grow, so the scroll bar cannot flip-flop mid-scroll. Any structural change or resize still recomputes the range from scratch. Documented trade-off: after the wide node scrolls out of view, the horizontal scroll bar keeps its width until the next non-scroll trigger recomputes it.Tests/VTScrollRangeIssue983Tests.pascovers the symptom (bottom is reachable) and both halves of the contract (grow-only during scroll, full recompute on structure change). Without the fix the symptom test fails, with it the suite is green apart from the two knownTestCopyHTMLfailures. Happy to adjust if you prefer a different semantic.🤖 Generated with Claude Code