Fix bottom rows being clipped when the panel is resized at high DPI - #254
Fix bottom rows being clipped when the panel is resized at high DPI#254leoshone wants to merge 3 commits into
Conversation
|
Please share the before after comparison. |
|
Here is the before/after comparison, taken in the same portable Notepad++ - same document (91 nodes, fully expanded), same window size, zoom 100%. Only the plugin DLL differs between the two runs. Before - the tree is scrolled to the very bottom (scrollbar reports the end), yet the bottom rows are physically outside the panel and the node path box is gone: After - all rows reachable, the horizontal scrollbar is back inside the tree client area, and the node path box reappears: Measured geometry at 150% DPI:
The screenshots were produced with a live geometry probe (control rects mapped into the panel's client space, |
AdjustDocPanelSize multiplied the pixel delta between the new panel size and the initial one by the desktop DPI scale. Both values are already in physical pixels, so on any monitor whose scale is not 100% the tree (and the node path box) grew s times faster than the panel itself and slid below the panel's client area. The tree control computed its scroll range from its own oversized height, so the scrollbar reported the end while the last (s-1)*growth/itemHeight rows were physically outside the visible panel: fully expanded long documents showed rows that could never be scrolled into view. Measurements at 150% scaling before the fix: tree bottom 213 px below the panel client area (5+ unreachable rows at 100% zoom), node path box 115 px below it. Positioning is now absolute - template rect plus the unscaled delta, with the tree ending above a node path box that is pinned to the bottom of the client area - which also makes repeated resizes idempotent instead of accumulated.
MSVC's windows.h defines max as a macro unless NOMINMAX is set, so std::max(...) failed to compile as std::(...). Parenthesize the call - the standard portable workaround - instead of touching the project's include settings.
The tree height is now derived from the node path box position instead of the raw height delta, so the variable is gone.
be21c0c to
2bf3b4e
Compare
…NPP-JSONViewer#255 opened - NPP-JSONViewer#251 was approved and merged - the small-pure-PR strategy works. - Upstream moved to fa8d2b9 (settings saved on exit via writeIfChanged, include reordering) and renamed our TREE_ZOOM key to TREE_ZOOM_LEVEL; documented the consequences for the next integration sync. - NPP-JSONViewer#253/NPP-JSONViewer#254 rebased onto fa8d2b9, all three PRs mergeable again. - NPP-JSONViewer#255 opened for the narrow jsonc recognition, with the forward pointer added to the NPP-JSONViewer#251 thread as planned.


Fix bottom rows being clipped when the panel is resized at high DPI
The bug
On a monitor whose DPI scale is not 100%, expanding a JSON tree fully and
scrolling to the bottom leaves the last few rows physically unreachable: the
vertical scrollbar reports that it is at the end, but the bottom rows are
simply outside the visible panel. The node path box at the bottom of the panel
disappears completely. The larger the panel (and the higher the DPI scale),
the more rows are lost.
Measured on a 150% DPI display (JSON Viewer docked, panel client 394x968):
Root cause
JsonViewDlg::AdjustDocPanelSize()multiplied the size delta between thecurrent panel size and the initially recorded one by
CUtility::GetDesktopScale():nHeightcomes fromWM_SIZEandm_lfInitialClientHeightfromGetClientRect- both are already in physical pixels. Multiplying thedelta by the DPI scale again makes the child controls grow
stimes fasterthan the panel itself on any scaled display (
s > 1). The tree controlcomputes its scroll range from its own (oversized) client height, so its
scrollbar is convinced it has reached the end while the overflow rows are
clipped by the parent dialog. At 100% scaling (
s == 1) the error is exactlyzero, which is why the bug only shows up on scaled monitors.
The fix
Position the resizable controls from the current client size instead of
accumulating scaled deltas:
node path box) is captured once when the dialog is created;
WM_SIZEeach control is placed at template rect + unscaleddelta, so its designed margins to the panel edge are preserved at any DPI;
node path box", with the node path box pinned to the bottom of the client
area - the layout is now self-correcting instead of accumulated.
This also fixes two adjacent effects of the same arithmetic: the needless
horizontal scrollbar caused by the oversized tree width, and the drift
between repeated resizes caused by truncating scaled deltas.
Verification
Measured with live Win32 geometry probes against the real plugin inside
Notepad++, at 150% DPI, with the tree fully expanded (
TVM_GETVISIBLECOUNT,TVM_GETNEXTITEM(TVGN_LASTVISIBLE), control rects mapped into the panel'sclient space):
reported as the final one while it was clipped;
box), all 91 rows of the test document reachable after scrolling to the
bottom, node path box visible again;
no drift, overflow stays at zero;
refresh, draw-on-open, jsonc recognition) all pass unchanged.