Skip to content

Test: Count a parked window at its nearest monitor's scale - #178

Merged
b-re-w merged 1 commit into
developfrom
feat/park-scale
Nov 9, 2026
Merged

b-re-w merged 1 commit into
developfrom
feat/park-scale

Conversation

@b-re-w

@b-re-w b-re-w commented Nov 9, 2026

Copy link
Copy Markdown
Member

run65 on this PC (primary 2880x1800 at 200 percent, two 2560x1440 at 125 percent to its right) gave NOT_DRIVEN for every scene: "the window's scale changed after it was parked: 192 then 120". The browser opens on the primary at 192 and the park at 9000,1000 is nearest the lower 125 percent monitor, so it re-lays out at 120, which is what a person's window there has.

The park check now requires the last traced layout DPI to equal the effective DPI of the window's nearest monitor (MonitorFromWindow + GetDpiForMonitor, on the per-monitor aware harness thread). Get-ParkScaleError in windows-features-lib.ps1 is pure; the selftest case nfr5_a_parked_window_counts_at_its_nearest_monitors_scale_only covers 192 then 120 at a 120 monitor (counts), the single 200 percent drop 192 then 96 at a 192 monitor (rejected), and a window left at 192 nearest a 120 monitor (rejected).

🤖 Generated with Claude Code

A window opened on a 200 percent primary and parked nearest a 125 percent monitor rightly takes
that monitor's scale, and the check that the scale never changed made every scene NOT_DRIVEN on
such a machine. The parked window must now settle at the DPI of the monitor it is nearest, which
still rejects a window that dropped to the system scale on a single 200 percent monitor.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@b-re-w
b-re-w merged commit 114c4c2 into develop Nov 9, 2026
3 checks passed
@b-re-w
b-re-w deleted the feat/park-scale branch November 9, 2026 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant