winforms
winforms copied to clipboard
dotnet
MDI child windows use hard-coded Visual Style Rendering
This issue has been moved from a ticket on Developer Community.
- Create an MDI container as the main application window (typical). (Set IsMDIContainer to true)
- Via code, add MDI child window using the standard way (create, set MDIParent to "this", then Show).
The child windows always display with the Windows 7 Aero style, regardless of OS, the theme, or the user preferences. Our sales folks have complained that our application doesn't look modern because they demo on Win10 and the child windows look 10 years old and inconsistent.
No reasonable workaround is available. Several reports of the problem online and no confirmed workaround is available.
Original Comments
Feedback Bot on 7/30/2020, 02:21 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Amy Li [MSFT] on 7/30/2020, 04:17 PM:
Hi Glenn,
Thanks for sharing your problem at here. This is a nice suggestion but not a real issue. So we will convert it as a Suggestion Ticket.
Thanks for help us build a better visual studio!
Glenn Wickman on 7/30/2020, 11:16 PM:
This isn't a suggestion, it's pretty clearly a bug. Please review the attached screenshot that shows the incorrect non-client area painting of only MDIChild windows. Other top-level windows paint correctly so this is inconsistency at the very minimum and, on a larger level, the MDIChild windows are completely ignoring all the Windows settings (themes, user colors, etc). I would also point out that on certain operating systems like Windows Server 2012, the issue doesn't exist. So it's also a bug that randomly manifests depending on the version of Windows.
I'm also not sure why you've tagged this report as "needs more info". I've literally given the repro steps and screen shots. I'm happy to provide more information if you tell me what else you'd like.
Amy Li [MSFT] on 7/31/2020, 04:20 PM:
Hi Glenn,
We are sorry that our response was misleading to you. We verified the MDIChild on win10 & win8.1, the tesult result as following screenshot. So your issue is Form1 and ChildForm have different window style in win10?
Win10:
Win8.1:
Glenn Wickman on 7/31/2020, 11:52 PM:
(private comment, text removed)
Feedback Bot on 8/4/2020, 10:42 AM:
This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
Original Solutions
(no solutions)
The same behaviour was observed in https://github.com/dotnet/winforms/issues/3029#issuecomment-645176986
Comments from customer:
The issue occurs on Windows 10, Windows Server 2016, AND Windows 8.1 (Your Win 8.1 screen shot appears to be from an installation that has had all UI styling turned off). In my tests, only Windows Server 2012 painted it according to the OS themes correctly. See attached screens.
Windows 8.1 Enterprise with Update (child windows incorrectly use Win7 styling)
Windows Server 2016 (Child windows incorrectly use Win7 styling)
Windows 10 (Child windows incorrectly use Win7 styling)
Windows Server 2012 (Child window is styled consistently with other windows)
So as you can see, the bug is that the MDI Child windows do not paint according to the OS/Theme styles. They always paint in the Windows 7 Aero style regardless of the actual settings (except on Windows Server 2012). Normal (non-MDIChild) windows paint correctly as do the system windows like MessageBox, so you end up with a UI that has a mix of old and correct styling.
@Amy-Li02-zz
This issue is same with: #3029 (comment)
Hm, I think this is not the same issue... But the problem with different styles must be defiantly solved. Our users have already complained about this :(
This is not a WinForms issue, if you create a C++ project from the "MFC App" template in VS and chose MDI settings ("Multiple documents", "Tabbed documents" disabled, project style "MFC Standard") you get the same behavior. WinForms just exposes what the OS provides, any native MDI application (even if not using MFC) should look this way.
As far as I understand MDI is an obsolete technology and never got updated as far as visual styles are concerned. WinForms will not be able to fix this because it doesn't control rendering the frame.
Windows 10 MFC App using MDI:
MFC App Wizard settings I used to configure the template:
@weltkante Yes, it does look like it's a bug in the Windows API in general- not specific to .NET or WinForms.
While it certainly looks like MDI support is not being maintained properly by Microsoft, I'm not seeing any evidence that it's an obsolete technology:
- There are still plenty of apps that rely on this structure as the optimal way to present their UI (Photoshop for example).
- I'm not seeing any documentation from Microsoft indicating that the MDI features are deprecated or recommendations that developers should abandon this UI paradigm.
- This type of UI option is still supported in Visual Studio by way of their templates and in their documentation which only encourages their use.
So the safe assumption would be that Microsoft doesn't want to fix it, doesn't have the resources/expertise to fix it, or can't find a reasonable workaround to offer. So they're essentially telling their developer community to "live with it" or invest millions into designing and rewriting the products to use a different UI/UX paradigms and then retrain the customer base on a new UI. And we all know how well that usually goes.
While I can't make promises for another team, I'm going to reach out to Windows to find out if there is something we can do to make this better for our customers. I'm hopeful we can find some sort of work around that perhaps WinForms could add to our implementation of MDI Child Windows. I don't like the inconsistency myself one bit, and I'll push Windows towards a platform fix, or at least some way for us to work around the issue. I'll report back when I hear anything.
We had a preliminary investigation and it looks like it may (?) be a bug in the Windows codebase. A deeper investigation is required and that requires time. Will update once we have more information to share.
This problem (error!!) has existed since Windows 10. Unbelievable that Microsoft Visual Studio Team has not solved this problem yet. I personally have been waiting for a solution for years!
We're going to take another stab at this in the 6.0 timeframe. I can't promise precisely when or whether the result will be a .NET Fix or a Windows bug yet.
This issue is being tracked by windows internally. Will update the status based on their resolution. Doing anything on the winforms side would need implementation of custom rendering of the non-client area. It would be better if it gets fixed on windows side and even native apps can benefit from it.
This does not affect just MDICLIENT class Windows; any HWND with WS_OVERLAPPEDWINDOW (or similar) that is a child of another overlapped window will loose DWM compositing, revealing the theme parts from the Window class (the win7 caption, frame, close/min/max, etc.) in the aero style rather than the modern theme parts from the DWMWindow class.
@RussKie What do you think are our chances that this will be fixed in Windows? Ironically this external bug is most wanted thing in WinForms repo :)
This bug affects our team as much as it affects you... And we do hope it gets fixed.
I had the same problem, so I decided to create my own MDI system in winforms, in case anyone wants to take a look, this is the link of the github repository: https://github.com/GabrielFrigo4/WinFormsMDI2
I believe the only option we have is to wait for a windows update to be pushed out that updates the dwm to composite child windows. I don't think winforms itself can fix this.
~~unless winforms decides to completely owner draw child windows but that's more of a headache than anything~~. Also that doesn't solve the core problem either.
@KlausLoeffelmann this is the answer to https://github.com/dotnet/winforms/issues/7641#issuecomment-1232103546
When it comes to MDI Windows, WinForms just follows the Windows/Office guidelines. It doesn't have to do with my/general personal preference, it's just a very functional reason: When multi-monitor display scenarios became common even in conservative work environments like Banks, Insurance Companies, Government Departments (all typical WinForms target audiences), MDI user interface just became totally unpractical: You simply can't drag a document to a secondary monitor, when you have a constraining MDI parent on the primary monitor. And with that (I say that from a very strong personal experience as a consultant in the area of migrating/modernizing Win32, VB6 and older WinForms/WPF apps in a previous life) End Users started to demand other UI paradigms.
Still, I recognize that we need to support existing apps with that - so, no, no one said anything about obsoleting it. All that I am saying is, that it'll be very likely that we (WinForms) won't invest in a scenario, that a) doesn't make sense in modern work environments, and b) that isn't very likely supported (in terms of modernizing) by Windows. Should they decide to introduce theming, then we would very likely pick that up and enable it. But I don't think it would make sense for us (WinForms) to start messing with a NC-Custom-rendering approach.
Multi-monitor scenario is the strong point for not to invest in self rendering MDI. But to fix more then 10 yeas old windows bug this is not a point at all. I arguing here to fix the bug in windows not to fix it by WinForms team...
And about Multi-monitor... WinForms support multi-monitor? Formally - yes, but in practices - no. Because multi-monitor without full HDPI support is nearly useless. And HDPI overhaul was promised in 5.0, then in 6.0, then in 7.0, now in 8.0... Also WinForms have a multi-monitor working alternative for MDI? - NO. WinForms have any multi-window layout other then MDI? - NO.
Yes, we would really like to have full HDPI support in WinForms, and modern multi-window layout that would work in multi-monitor mode... But we have what we have :(
I arguing here to fix the bug in windows not to fix it by WinForms team...
I get that. But there is no point in in discussing this here, that's all I am saying. And I am personally not really optimistic, Windows will address this. All the more, since it's not a bug. It's just not the way most of likes this to be rendered.
And HDPI overhaul was promised in 5.0, then in 6.0, then in 7.0, now in 8.0...
And we gradually have been working on HDPI issues in the 5, 6, 7 timeframe and we will be working on this for 8. As I said in other contexts before: We are prioritizing our tasks by requirements which are changing over time, and sometimes changing really quickly. They are changing because of the Zeitgeist, and they are changing, because the community takes on issues, and that frees time for us to deal with other urgent matters, sometime issue which you don't see immediately. Please keep in mind, this team works on the .NET Framework Designer, on servicing issues with that, on the .NET Framework WinForms runtime, on servicing issues with that, on the VB .NET Application Framework and its service request, on bringing over the .NET Designer for .NET AND .NET Framework to OOP, on the .NET VB Application Framework and also closely cooperates with the Project System Team for the Visual Basic AppDesigner Project Property pages. And then we're modernizing the WinForms .NET runtime and do our best, to channel our passions about thinking of new cool WinForms functionality and how we can get that done in the time remaining. Please take into account, that also new laws around Accessibility (A11Y) brings us constantly in situations, where we need to address A11Y issues quite promptly, and on top: those A11Y issues are really important to us personally. And if something like a Windows 10->Windows 11 UI-redo comes along, then there are also internal issues, which need to be addressed in time. So, if your desire to have things quicker grows too much, feel free to also reprioritize your tasks and step in. That's the beauty of WinForms being Open Source, after all!
WinForms have any multi-window layout other then MDI? - NO.
I am sorry: That's just plain wrong. You do can have as many Forms on the screen as you like. We support all kinds of different Window styles on top. The last time I checked, Paint.NET (there is also a free version available for download) for example was a WinForms App. And a .NET (not Framework) WinForms App on top of that. WinForms Apps render just fine in SystemAware HighDpi Mode. Yes, there are issues with PMV2, which we are constantly addressing in .NET. And yes, there are also issues with Dark Mode. But yes, we do our best to also address those. And it may not yet look as pretty as it's supposed to be, but this is a very cool WinForms App that addresses our top requested features (Dark Mode, HighDpiMode rendering): This is A VERY COOL WinForms App and is super-useful on an modern Windows 11 HighDpi machine.
It works on my Multi Monitor scenario PERFECTLY:
I do not want to jump on the ongoing conversation but wanted to update on what windows team think on MDI visual styles. They did resolve internal tracking bug as won't fix given the legacy nature and cost involved. It would be nice to redirect MDI visual styles/theming questions/feedback via windows feedback channel to give the team justification for fixing this.
@KlausLoeffelmann I'm afraid we'll go into a tough offtopic here too :)
All the more, since it's not a bug. It's just not the way most of likes this to be rendered.
I disagree, because this behavior depends on the version of Windows. For example in Windows Server 2012 it's just rendered as it must. But I agree as you said:
there is no point in in discussing this here
😥
WinForms have any multi-window layout other then MDI? - NO.
I am sorry: That's just plain wrong. You do can have as many Forms on the screen as you like. We support all kinds of different Window styles on top. The last time I checked, Paint.NET
Ok, I'll rephrase a little: WinForms have any multi-window layout engine out of the box other than MDI?
Paint.NET is a great app. And if you look at it you will not believe that it uses WinForms (as I know - WinForms + WPF). I mean, its windows layout, rendering etc. are all done by hand...
It works on my Multi Monitor scenario PERFECTLY:
🤔 hmmm I was always thinking that PMV2 == (or even >=) DPI switch on the fly. Am I wrong? Paint.NET can't survive (visually) DPI switch - need to be restarted...
-----UPD-----
@dreddy-work
do not want to jump on the ongoing conversation but wanted to update on what windows team think on MDI visual styles. They did resolve internal tracking bug as won't fix given the legacy nature and cost involved. It would be nice to redirect MDI visual styles/theming questions/feedback via windows feedback channel to give the team justification for fixing this.
It was to be expected, but still there was hope... 😢
@KlausLoeffelmann Our further discussion is useless :( If only to clarify the question with changing the DPI on the fly...
If only to clarify the question with changing the DPI on the fly...
I am not really sure, what you mean by that? Do you mean react in a Form or Control when the DPI has changed because you dragged a Form from one Monitor to another which has a different resolution and/or scaling?
Both scenarios are supported in the HighDpi Modes SystemAware and PMV2. The difference is: SystemAware does this automatically with somewhat lesser quality. The Primary Monitor rules the HighDPI rendering quality, so to say; on Monitors with different scaling, the content/controls are scaled up and down by bitmap resizing. In PMV2, basically every Form/Window is responsible to scale its content by itself. To ease this overhead, WinForms have started to that for you for many control scenarios, but - as I said - for some we haven't yet. When it comes to custom rendered content, there can't be any support - you just need to scaled-render your content how you literally see fit. That's where the Control.DpiChangedBeforeParent and Control.DpiChangedAfterParent can help you with.
@KlausLoeffelmann
I am not really sure, what you mean by that?
I mean changing this settings:
or equivalent:
Apparently it's all my bad English...
In my understanding to fully support changing this option during app running, the app must be PMV2 compatible.
And in response to your
It works on my Multi Monitor scenario PERFECTLY:
I was surprised, because I always thought that that Paint.NET is SystemAware because it needs to be restarted after changing the above settings.
@Amy-Li03
Windows Server 2012 (Child window is styled consistently with other windows)
Not what I would say "consistent" but it proves a point. The title bar of MDI child window is not drawn by DWM, so the "Basic" visual style is used instead. But the default "Windows Aero" (aero.msstyles) still contains the old Windows-7 style visual styles borders.
The new theme that we now called "Windows Basic", (which is actually not a Basic theme but Aero Lite, aerolite.msstyles) , used in Windows Server 2012/R2, and newer versions of Server Core, does have an updated visual styles window border that matches the DWM border.
So the solution is to update aero.msstyles. Can't imagine why Windows 11 didn't do this (Windows 11 does have an overhaul to aero.msstyles).
@driver1998 @dreddy-work @Amy-Li03 @kirsan31 @merriemcgaw @KlausLoeffelmann
I create theme Form library that fixed this issue
test project in .Net Core 6
Any suggestion is Welcome
