[frKieran]

On the Mario tab the variables stop partway across the tab: the rest of the tab is blank and a horizontal scrollbar appears, so most columns can only be read by scrolling. Main Save has the same problem, and Memory and Ghost lose a few pixels. How much is visible depends on the window width (the panel always ends 549 px before the right edge on Mario, 325 px on Main Save), so a maximized window can hide it. I see it on every release I tried from 0.7.0 on (0.7.0, 0.7.2, 0.9.0, 0.9.1), but not on 0.6.3.

Before / after (Mario tab, 1070 px wide window):

These four panels are anchored on all four sides, and their designer size is a few pixels larger than the area their parent gives them (Mario: 703 px wide at x = 2, in a Panel2 that has Padding = 2 and is about 704 px wide in the designer). On .NET 8+, WinForms' DefaultLayout.UpdateAnchorInfo has a special case for this: when an anchored control's new right (or bottom) edge lands outside its parent and the previous anchor didn't, it keeps the previous anchor ("reuse old anchors info to prevent losing control beyond right edge"). Here the previous anchor seems to be the one recorded while the panel still had UserControl's default 150 px width: at the designer size the panel comes out about 150 px wide, and it only grows by however much the tab grows. On 0.6.3 (.NET Framework) the same layout just let the panel overhang its area by 3 px.

Every other tab with this layout (Object, HUD, Triangles, Camera, Misc...) already uses Dock = Fill. This PR does the same for the four affected panels. Panel2's padding still gives the 2 px margin, so the panel fills the tab as intended.

Tested on Windows with Release builds of this branch and of the same change on v0.9.1, measuring each panel's window against its parent. In a 1070 px wide window, the Mario panel is 807 of 811 px (was 260), Main Save 476 of 480 (was 153) and Memory 165 of 169 (was 150), and Ghost now fills its group box (it was short by about 30 px across and 60 px down). The Mario panel stays filled through resizing, minimizing, switching tabs and the pane-layout buttons, and the other tabs are unchanged. Water, QFrames and Actions are also anchored, but their designer sizes fit, so they aren't affected.

Read also:
I've previously reported this off-site and people have not experienced the issue I am describing here. I think I have a theory as to why. This is only meant to explain why it varies between users, not part of the bug report: the fix itself has nothing to do with DPI scaling, since with Dock = Fill the panels fill the tab either way. (not confirmed: I haven't tested this on a machine where the bug doesn't happen, but it's a plausible explanation): that rule only runs when ScaleHelper.IsScalingRequirementMet is true, meaning the process is per-monitor DPI aware or the system DPI isn't 96. STROOP's manifest says dpiAware=false, and per the WinForms source a DPI-unaware STROOP sees 96 DPI and never hits the rule. But on my machine (Windows 11 25H2, build 26200, two monitors at 100%) Windows starts DPI-unaware programs as per-monitor aware anyway: user32's InitProcessDpiAwareness forces it when a system flag is set and the display scaling is at most 125%. It did so for STROOP, for a copy whose manifest says <dpiAwareness>unaware</dpiAwareness>, and for a test exe with no DPI setting at all. So whether the panels get cut depends on how Windows starts STROOP (Windows version or settings, display scaling, Wine), not on STROOP's settings. Even where it happens, a window wide enough for every column hides it.

🤖 Generated with Claude Code, so take with a grain of salt.