Update the OwnerDraw flag when BackgroundImage changes

[LeafShi1]

Fixes #13823

Root Cause

The OwnerDraw property of the Button control incorrectly returns false when BackgroundImage is set during early initialization. This is due to the OwnerDraw logic checking BackgroundImage == null before the control's handle is created, which causes a premature fallback to the system renderer. As a result, even though BackgroundImage is later assigned, it is ignored during rendering in FlatStyle.Standard mode.

Proposed changes

• Invoking UpdateOwnerDraw in BackgroundImage property of Button.cs to update the OwnerDraw flag to ensure correct visual behavior
• Place the DrawButtonBorder method after PaintImage.
• Draw the background image starting from the vertices of the ClientRectangle, rather than just drawing the content area.
• Remove the border drawing logic for flat mode, ensuring that the border completely surrounds the button (in classic mode, flat mode buttons also do not have rounded corners).

Customer Impact

• The BackgroundImage of Button can be displayed when the FlatStyle is Standard in DrakMode

Regression?

• Yes

Risk

• Minimal

Screenshots

Before

The BackgroundImage of Button is not displayed when the FlatStyle is Standard in DrakMode

After

The BackgroundImage of Button displayed when the FlatStyle is Standard in DrakMode

Test methodology

• Manually

Test environment(s)

• .net 10.0.0-rc.1.25418.105

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull Request Overview

This PR fixes an issue where Button controls with BackgroundImage fail to render properly in dark mode when using FlatStyle.Standard. The problem occurs due to premature evaluation of the BackgroundImage property during early initialization before the control's handle is created.

• Adds an IsHandleCreated check to the OwnerDraw property logic
• Delays the BackgroundImage null check until after handle creation
• Ensures buttons with BackgroundImage properly use custom dark mode rendering

[codecov]

Codecov Report

❌ Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.13077%. Comparing base (285bb9d) to head (9e82a5f).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main      #13824         +/-   ##
===================================================
+ Coverage   77.10424%   77.13077%   +0.02652%     
===================================================
  Files           3273        3273                 
  Lines         644936      644932          -4     
  Branches       47692       47693          +1     
===================================================
+ Hits          497273      497441        +168     
+ Misses        143982      143820        -162     
+ Partials        3681        3671         -10     

Flag	Coverage Δ
Debug	77.13077% <0.00000%> (+0.02652%)	⬆️
integration	19.00838% <0.00000%> (+0.02743%)	⬆️
production	51.97881% <0.00000%> (+0.05907%)	⬆️
test	97.41256% <ø> (ø)
unit	49.37687% <0.00000%> (+0.03923%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KlausLoeffelmann]

@Epica3055, how is tbis related to the changes for RC2?

[LeafShi1]

@Epica3055, how is this related to the changes for RC2?

This fix is unrelated to RC2.
The original issue is #13720, but there are two pull requests (PRs) addressing this issue.

1. Draw background image for button in dark mode #13809 (already in RC2). After testing, this only addresses the issue where the background image doesn't display when the button's FlatStyle is Flat & Popup.
2. This pull request provides a supplementary fix for the issue where background images do not display in Dark Mode when the button's FlatStyle is set to Standard.

[KlausLoeffelmann]

Makes sense.
Please make sure, we would get the other edge case also taken into account.
@merriemcgaw - this would make very much sense to also take in RC2, if tactics agree.
Argument for late discovery: All edge cases, which CTI found out after implementing recent fixes. All completely scope to dark mode AND to the respective narrow area, and without ANY chance to regress the light mode render path.

@LeafShi1, @Epica3055: If we would get green light for RC2, this would need to be back ported.
All: Before we backport this, let's take @Olina-Zhang another look at it, to see, if we would find more edge cases in this area, so we do not need to go another time to tactics to ask for backporting a fix!

Thanks!

[LeafShi1]

@KlausLoeffelmann @merriemcgaw Based on the test results of this PR, I need to confirm should OwnerDraw be enabled in Dark Mode with FlatStyle = Standard?

If OwnerDraw should not be enabled

• The BackColor, ForeColor, and background image settings for the Button control do not take effect. This mean that the current issue is not a bug, but rather a By Design issue. Please confirm this.
• A further question is: For other controls (such as Label, GroupBox), color property settings currently take effect in DarkMode. If OwnerDraw is not enabled for Button, this will lead to inconsistent UI styles. Should OwnerDraw be disabled for these controls as well to maintain consistency?
• Also, it's important to note that in .NET 9.0, color property settings for Button do take effect, so this is currently a regression.

If we decide to enable OwnerDraw to restore the effects of these properties, some existing drawing logic (such as the code at

winforms/src/System.Windows.Forms/System/Windows/Forms/Controls/Buttons/RadioButton.cs

Lines 174 to 185 in 9634900

	private protected override bool OwnerDraw =>
	// Order is key here - do NOT change!
	// We want NO owner draw ONLY when we're
	// * in Dark Mode
	// * when _then_ the Appearance is Button
	// * but then ONLY when we're rendering with FlatStyle.Standard
	// (because that would let us usually let us draw with the VisualStyleRenderers,
	// which cause HighDPI issues in Dark Mode).
	(!Application.IsDarkModeEnabled
	|| Appearance != Appearance.Button
	|| FlatStyle != FlatStyle.Standard)
	&& base.OwnerDraw;

) may need to be adjusted.

[KlausLoeffelmann]

What I do not understand is:
When the Button has a border, why would the background "shine through"?

We paint:

• Background
• BackgroundImage
• Border

If we are not deflating the Bounds, aren't we then painting over the Image? What if the Image got important markers in its outer border?

[LeafShi1]

According to the previous logic, our drawing order was incorrect.

1. Background color
2. Border
3. Background image

This has now been corrected.

Under the original logic

• The background color was drawn according to the ClientRectangle (the background color and background image in Classic are drawn using rect.Inflate(-Control.FlatAppearance.BorderSize, -Control.FlatAppearance.BorderSize);).
• The border was drawn after indenting the ClientRectangle by one pixel (the border in Classic is drawn using r.Inflate(1, 1);).
• The background image was drawn after subtracting the ClientRectangle from Control.borderSize (the background image in Classic is drawn using rect.Inflate(-Control.FlatAppearance.BorderSize, -Control.FlatAppearance.BorderSize);)).

So, under dark mode, the background color size > the border size > the background image size.

[KlausLoeffelmann]

Not holding this off, since it is too niche.
Let's take this as it is, so we can go forward.

@merriemcgaw FYI.