Winforms: [API Addition] Use ScollBar control for ScrollableControls to allow usage of Custom ScrollBarRenderers.

[AraHaan]

I think that replacing Scrollbars can be a pain in the butt when you want to theme an winforms application. What if someone wants to make the entire form look like the UWP dark theme on Windows 10 but hard coded as dark theme?

I think the application should be able to colorize the scrollbars without:

1. Using undocumented windows api that can always change or break.
2. Reinventing the wheel and having to create their own hacked together scrollbar for a hacked together class that would end up being the same scrollable controls we got now.

I am also in the works of investigating NCPAINT on forms themeselves and getting the real bounds of that area; I know for sure at least on 10, 8, and 8.1 those bounds should be rectangle, on windows XP ~ 7 rounded rectangle using Regions. I was thinking of somehow inside of Form class calculate it by OS version the true bounds; then use a custom FormNCRenderer class (which I will intend to be subclassable) which would contain the painting of the NC area; text; and icon with system menu; which itself would allow use of an ContextMenuRenderer; and an for the Minimize; maximize; close; and help buttons allow yet another renderer separate from FormNCRenderer to keep it small and concise and readable.

I think if we want to allow theming we should allow the user to override the system painting as well entirely.

I hope my 'hacking' for this on my program can benefit everyone eventually.

[AraHaan]

I was told to make this from issue #357.

[AraHaan]

Note: Implementation will come at No ETA.

This is to ensure it is not rushed and is tested locally.

[RussKie]

/cc: @nikolayxhd you may be interested in this discussion/FR

[Wagnerp]

I also have the same question as noted in #2054

[merriemcgaw]

@OliaG please put this on our list of features to discuss in 5.0 planning work.

No commitments to timelines or anything yet. But it's officially on the radar for discussion.

[AraHaan]

@merriemcgaw perhaps you can assist me on getting the real NC bounds of the form itself and the location of the buttons and stuff that gets painted in the NC area based on the OS and their sizes and stuff factored in. Because I plan on having form NC styling be an optional thing as well via a renderer. However the renderer probably needs some default values where if they are the default colors then skip NC override from system and just use what the system gives.

[weltkante]

@AraHaan GetWindowRect? If you mean the shadow around the frame, that might not be part of the NC area in the first place, it could be a seperate noninteractive window just for visuals, or an effect applied during composition by the DWM. At least some applications render the frame shadow in a separate window (which you can notice when the window stops responding to its message loop, the shadow then sometimes gets out of sync with the window position, which could not happen if only one HWND was used)

The various offsets for sizing and positioning buttons can be read from the system parameters (frame and core controls) and theming API (other common controls), I don't know it on top of my head and would have to research it again though.

Form NC styling has only limited support, see e.g. here. The supported way is basically turning off the NC area and doing the frame yourself in the client area. Doing it in an unsupported way by overriding NCPAINT is possible but you have to override a whole bunch of undocumented behavior, the DefWindowProc tends to update the form NC area on arbitrary events (at least it used to) causing flickering of the original buttons if you just override NCPAINT. Your best chance is to research open source code which sucessfully has done it, e.g. Chrome Browser UI or WPF WindowChrome.

That said, I don't know if its the right approach to override form NC painting for adjusting the scrollbars, as far as I know it's not going to be supported. The best approach IMHO would be not displaying the builtin scrollbars and just providing API to place explicit scrollbars. Anything else would require major work to document currently undocumented behavior, otherwise WinForms wouldn't be stable across OS releases. (Though I'll be happy to be proven wrong if there exists documentation I'm missing.)