Fix ItemHeight of ListBox is not scaled on high DPI in OwnerDrawFixed mode#14740
Open
ricardobossan wants to merge 2 commits into
Open
Fix ItemHeight of ListBox is not scaled on high DPI in OwnerDrawFixed mode#14740ricardobossan wants to merge 2 commits into
ricardobossan wants to merge 2 commits into
Conversation
An `OwnerDrawFixed` `ListBox` keeps its fixed `ItemHeight` (the reporter's sample sets `25`) when the control is autoscaled. At higher DPI the font grows but the rows stay their design-time height, so the items look cramped. .NET Framework scaled the item height; .NET (Core) doesn't. - Scale the `OwnerDrawFixed` item height by `factor.Height` in `ListBox.ScaleControl`; the same scaling pass that already scales padding and margin. The result is clamped to `[1, 255]`, and a height-axis guard keeps a partial pass from applying the factor twice. - `ScaleControl` is the entry point that both `AutoScaleMode.Font`/`Dpi` and PerMonitorV2 route through, so no per-DPI-message hook is needed. - Owner-draw fixed `ListBox` items are the correct height at higher DPI instead of the design-time height. Long-standing customer report; does not occur on .NET Framework. - Versus .NET Framework: yes (Framework scaled it, Core didn't). Not a recent .NET regression. - Low. Runs only for `OwnerDrawFixed` during a real scaling pass, reuses the `ItemHeight` setter, and clamps so it can't throw. `Normal`/`OwnerDrawVariable` unaffected. Sample is `HighDpiMode.SystemAware` (reads DPI at startup): change the scale, then **relaunch** to 150%: rows stay at `ItemHeight = 25` while the font scales up (cramped). 150%: item height scales (25 > ~38), keeping the 100% proportions. - Unit tests - No accessibility surface change; item height only affects layout. - Windows 11, .NET (main).
ricardobossan
added
the
waiting-review
ricardobossan
changed the title
LeafShi1
reviewed
Jul 15, 2026
LeafShi1
reviewed
Jul 15, 2026
Math.Round uses banker's rounding by default, so .5 midpoints could round down (15 * 1.5 -> 22) and re-introduce the cramped rows this fixes. Add tests covering the midpoints (25 -> 38, 15 -> 23) and the height-axis guard that keeps a Height-excluded scaling pass from applying the factor twice.
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
2 participants
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 #6382
Proposed changes
An
OwnerDrawFixedListBoxkeeps its fixedItemHeight(the reporter's sample sets25) when thecontrol is autoscaled. At higher DPI the font grows but the rows stay their design-time height, so the
items look cramped. .NET Framework scaled the item height; .NET (Core) doesn't.
OwnerDrawFixeditem height byfactor.HeightinListBox.ScaleControl; the samescaling pass that already scales padding and margin. The result is clamped to
[1, 255], and aheight-axis guard keeps a partial pass from applying the factor twice.
ScaleControlis the entry point that bothAutoScaleMode.Font/Dpiand PerMonitorV2 routethrough, so no per-DPI-message hook is needed.
Customer Impact
ListBoxitems are the correct height at higher DPI instead of the design-timeheight. Long-standing customer report; does not occur on .NET Framework.
Regression?
Risk
OwnerDrawFixedduring a real scaling pass, reuses theItemHeightsetter, andclamps so it can't throw.
Normal/OwnerDrawVariableunaffected.Screenshots
Sample is
HighDpiMode.SystemAware(reads DPI at startup): change the scale, then relaunch toBefore
150%: rows stay at
ItemHeight = 25while the font scales up (cramped).After
150%: item height scales (25 > ~38), keeping the 100% proportions.
Test methodology
Accessibility testing
Test environment(s)
Microsoft Reviewers: Open in CodeFlow