DarkMode (b) DarkModeButtonRenderer

[KlausLoeffelmann]

Add correlating DarkMode Button renderers to the existing Button renderers.

This way, we are becoming completely independent of the XP-based VisualStyle rendering (and most of all incomplete theming for certain situations, like the Button rendering for 96DPI/100% scaling scenarios).

Fixes #11949.

Note:
For Preview 5, we are very defensively activating the new Renderers, and do a more intensive testing for Preview 6. This means:

• Nothing changes, if we're in LightMode. We're not picking up any new Win11 compatible styles for now.

• In contrast to the documentation, we're rendering EVERY FlatMode ourselves (and have so all along) - also the default FlatMode. That means, if VisualStyles are enabled, we're still controlling the paint-pipeline (handling OnPaint), we're just delegating certain parts down to the VisualStyleRenderer (which does not work reliably for dark mode and does not work in 96 DPI altogether.) Our initial assumption that the native Win32 System button doesn't render dark mode correctly is wrong: It does, and it does so in every HighDpi mode (scenario tested by CTI), even with animation support. We are just not using it (and never have), when the user is not explicitly opting in by setting the FlatStyle to System. This is what the docs need to be updated for.

• For that reason, for DarkMode and FlatStyle.Standard, we're picking up the internal SystemRenderer, except for cases when we're rendering with images, as the SystemRenderer is NOT able to render images (and never was). In case of using Images, we're using the new DarkMode FlatRenderer, because that is style-compatible with the SystemRenderer.

• For the other styles, we're using the new DarkMode renderers respectively (Again, LightMode is not affected), we're not introducing any new Win11 styles for Preview 5.

[codecov]

Codecov Report

Attention: Patch coverage is 30.54711% with 1371 lines in your changes missing coverage. Please review.

Project coverage is 76.47110%. Comparing base (f2060df) to head (b1bfd78).

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main      #13408         +/-   ##
===================================================
+ Coverage   75.42791%   76.47110%   +1.04319%     
===================================================
  Files           3230        3240         +10     
  Lines         639213      640319       +1106     
  Branches       47303       47410        +107     
===================================================
+ Hits          482145      489659       +7514     
+ Misses        148044      147077        -967     
+ Partials        9024        3583       -5441     

Flag	Coverage Δ
Debug	76.47110% <30.54711%> (+1.04319%)	⬆️
integration	18.73064% <18.23708%> (?)
production	50.82504% <30.54711%> (+2.42533%)	⬆️
test	97.40114% <ø> (ø)
unit	48.21959% <28.97670%> (-0.18013%)	⬇️

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.

[Copilot]

Pull Request Overview

This PR introduces a new dark-mode–aware button rendering system alongside minor tweaks to the toolstrip renderer.

• Adds four sub-renderers (Standard, Flat, Popup, System) under ButtonDarkModeRenderer for WinForms buttons in dark mode.
• Updates ButtonBaseAdapter/ButtonBase to select and use the new dark-mode adapter when dark mode is enabled.
• Toggles a flag in ToolStripSystemRenderer to use the alternative dark-mode path and consolidates pen creation in its dark-mode border renderer.

Reviewed Changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/.../ToolStripSystemRenderer.cs	Flip isSystemDefaultAlternative flag to true
src/.../ToolStripSystemDarkModeRenderer.cs	Hoist borderPen creation out of branches
src/.../Controls/Buttons/DarkModeRenderer/*	New dark-mode renderer classes & factory
src/.../Controls/Buttons/DarkModeRenderer/ButtonDarkModeRenderer.cs	Core dispatcher for dark-mode button rendering
src/.../ButtonInternal/ButtonDarkModeAdapter.cs	New adapter to route RenderButton calls
src/.../ButtonInternal/ButtonBaseAdapter.cs & ButtonBase.cs	Hook up dark-mode adapter via OwnerDraw and CreateDarkModeAdapter
Winforms.sln	(Unrelated) added AI-Prompts and GDI solution items

Comments suppressed due to low confidence (1)

Winforms.sln:212

• Solution file now includes AI-Prompts and GDI entries unrelated to WinForms code. Remove these to avoid polluting the main solution.

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "AI-Prompts"...

[Copilot]

[nitpick] Both border-thickness constants are zero, making the switch on isDefault a no-op. Either consolidate into one constant or clarify if different values are intended.

Suggested change

	private const int DefaultButtonBorderThickness = 0;
	private const int NonDefaultButtonBorderThickness = 0;
	private const int ButtonBorderThickness = 0;

[JeremyKuhne]

There is more feedback to address (maybe an hour or two of work), but nothing that blocks getting this in for the next preview. Approving with the understanding that we'll address with a follow up issue to track.

[JeremyKuhne]

Cref for VisualStyleRenderer?

[JeremyKuhne]

Would be better as a cref for the events.

[JeremyKuhne]

What improvements are needed? As public documentation it would be better to say something like.

Suggested change

	/// Dark mode works to some extent, but improvements are needed.
	/// Partially supports dark mode.

And then make sure we have tracking issues around what we might be able to address.

[KlausLoeffelmann]

#13605

[JeremyKuhne]

What does this mean for the user? Does it really work well if 3d effects don't render? I don't really understand this, but I would guess you might be saying something like:

"Generally, works well in dark mode, with the exception of ..."

[KlausLoeffelmann]

Note, that this is describing a status quo, which has been changing over the time up to a point where the docs often no longer reflect the presents. The docs are still stating things like certain Borderstyle effects (not only for buttons), which are no longer true in general. For example, many controls have a BorderStyle 3D, which no longer resemble any 3D effect. But then we have control like the RichTextBox, which still does that in the same way as under Windows 95.

That was the original motivation behind the Visual Styles, which became then strongly connected to the dark mode changes, and the reason, I would argue to revisit the VisualStyles approach, should it come to it (resources, mandate).

[JeremyKuhne]

What are standard style buttons? Is there a cref that could be used here? Or another link that users can follow to understand this from docs?

[JeremyKuhne]

Comment is duplicated. Please do not use ! in comments.

[KlausLoeffelmann]

Ah, damn. My bad. Noted.

[JeremyKuhne]

A comment why we're skipping for dark mode would be useful.

[JeremyKuhne]

"Should" seems to imply that there is a follow up here. Is there something we should be tracking?

[KlausLoeffelmann]

It's maybe phrased a bit awkwardly. We need to update the docs rather. They imply that it should. It's now added to the list, and I ping @adegeo for it and talk to him!

[JeremyKuhne]

nit: Shouldn't need to add comments to overrides unless you need to change the docs. The less copies of documentation we have around, the less likely we are to have some copies lacking updates.

[KlausLoeffelmann]

Added that rule to the Copilot-Instructions. It should not happen again (if you use that to generate the XML), and I will be working to get that into account for pure refactotoring purposes.

[JeremyKuhne]

Where is this overridden? If it isn't it should be sealed and virtuals removed. In either case, the constructor should not be public.

[KlausLoeffelmann]

It's internal, and I kept the extensibility for us internally in mind. At that time, I did not know, if sealing a class would be final, but if I understood correctly, it is not. Added to the list!