[Proposal] Add an ScrollBarRenderer property to all classes implementing ScrollableControl and use that to render the scrollbars.

[AraHaan]

Is your feature request related to a problem? Please describe.

The problem in general is no clear easy way to override what the default scrollbars look like in all ScrollableControls (including Forms themselves). This is done by applications like Firefox, Discord, Visual Studio, etc for example (despite them not using Windows Forms) it makes them look nice as then they make the scrollbars match the look and feel of the application. However let's say for example you want to hard code themes on your application (based on if the user configured in their system's settings to use dark or light theme on Windows) to have your application then recolor itself based on that, Well it would work, but then the scrollbars prove more than impossible to do without extensive hacks and changes to classes within the Windows Forms libs to expose the scrollbars on all scrollable controls. Or they could try other means that will may not work including: p/invoke, etc that would then result in nothing being changed because the ScrollBar might be System.Drawn to every ScrollableControl when AutoScroll is true.

Describe the solution you'd like and alternatives you've considered

To expose a new property to ScrollableControl or whatever class provides Scrollbars (vertical and horizontal) to all controls that can have them enabled and the implementation to AutoScroll on how it actually makes the scrollbars and renders it. The code would then default that property to the default renderer, then when it goes to draw or make the ScrollBars it then uses that property allowing one to customize it easier.

Such implementation could be as simple as this being added:

namespace System.Windows.Forms
{
public class ScrollableControl: // anything else that it derives from.
{
+    /// <summary>
+    /// Gets or Sets the Renderer to use for the ScrollBars when AutoScroll is true
+    /// and when one of the scrollbars is enabled (horizontal or vertical). This allows an
+    /// application to simply override the default renderer for them.
+    /// <summary>
+    public ScrollBarRenderer ScrollBarRenderer { get; set; }
// then change anything else that actually makes the scrollbars and draws them to use this new property.
};

And basically have every renderer responsible for providing the following:
Settting the Images to use for the buttons on the scrollbar and colors of them, the colors of the knob (thumb) on every scrollbar, the color of the track of the scrollbar, etc that can be used to theme the entire scrollbar. Then have that code that draws them access all of that information from the property added so that way it can do the drawing.
The renderer could also have an option so if the user wants to self draw it too with a property that if set to true would call the renderer's Draw() method.

Real world Scenarios: There are a ton of them, ShareX is one of such programs that tries to provide the looks that UWP provides while being Windows Forms (even though it does have a version in the Microsoft Store that still uses Windows Forms), My program as well that is also on github I call it Els_kom, I basically try to do a lot more than what ShareX does by extending some of it's code they use on ShareX itself. Specifically ShareX could never override the scrollbar without using p/invoke methods (that might not support UWP or Microsoft Store versions), I tried to myself but failed and resulted in code I could never push to github using p/invokes since it done nothing to change anything at all.

Alternatives? There looks to be hardly no other way to change them on all controls other than subclassing them all just to override the WndProc and maybe get lucky to override the drawing of the scrollbars on the control itself if it lets you, then have the overridden WndProc call the control's original one. All of which seems like an hack to me when the underlying issue should be to expose a single property (possibly here as I propose) and then having all of the controls use that property to render the scrollbar.

Will this feature affect UI controls?

Yes, It will affect on how you can make their scrollbars look like by exposing an ScrollBarRenderer property to all controls Implementing ScrollableControl.

Will VS Designer need to support the feature? I do not see why not, but probably have it optional.
What impact will it have on accessibility? None, it just makes it easier to change the looks of the scrollbar without some unneeded p/invoke hacks or w/e. Besides I think all ScrollableControls actually use the ScrollBar control just does not expose it so we can override how the scrollbar looks, this is why I want this property added so we can do just that even at the form level just without explicitly exposing the actual scrollbars that should be internal anyway because I feel like this been lacking for years.

Will this feature need to be localized or be localizable?
Something like this, Nope. The Property would only be possible to set inside of code, or in the designer cs file of any form / control.

Can I implement this? I can, just need to know where it goes about drawing the scrollbars when AutoScroll or when the horizontal / vertical scrollbars are enabled. When that is done I would have to also test it then as well.

[merriemcgaw]

This is a cool idea, and we're interested in it. But, this is an extremely large feature that will require a lot of planning and design discussion. It is in line with some of what we want to do in future releases. Before we go very far down this path I want to talk to the Windows team about whether they have anything we can leverage. I would hesitate to go deeply into the design until we have this conversation.