-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MDI child windows use hard-coded Visual Style Rendering #3691
Comments
The same behaviour was observed in #3029 (comment) 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 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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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: |
@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:
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. |
Tagging @OliaG for discussion as well. |
Any news? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Guys, instead of this bumping, pls vote 👍 to the first post. |
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. |
This comment has been minimized.
This comment has been minimized.
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. |
Any News 4? |
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.
|
@KlausLoeffelmann this is the answer to #7641 (comment)
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. And about Multi-monitor... 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 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 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!
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 :)
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:
😥
Ok, I'll rephrase a little: 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...
🤔 hmmm I was always thinking that PMV2 -----UPD-----
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... |
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 |
@driver1998 I create theme Form library that fixed this issue test project in .Net Core 6 Any suggestion is Welcome |
does that use the DwmWindow msstyle class? |
Thank you for this work! And I want to notice that we already have one attempt. My personal opinion is that I will not use a third-party mechanism until it is tested and added to WinForms. |
1- get current loaded msstyle form registry
2- get atlas image from msstyle Stream 3- get operating system informathion from msstyle 4- split atlas image according to DwmWindow msstyle classs |
this them load default operating system setting if the developer doesn't change it not completely difference Theme I tested it for a few months on most operating systems and on different devices |
In my experience, if you wish to get some valuable team feedback / help on any new feature, then you need to create a PR... |
Thanks for the effort, we definitely appreciate! I'll take a look - can't promise when exactly, but I wanted to give some feedback already that I have it on my radar. I am a bit reluctant though to see it's done by NC-rendering, to be honest - but then again I don't want to jump to conclusions before having taken a look at the demo, anyway. |
@memoarfaa: Could you update the demo so it includes the necessary runtime components? |
Hello, Since Windows 8, Windows uses DWM to render windows. DWM window frame doens't apply to MDI child windows. |
The core issue is that the bitmaps in the visual style weren't updated in the WINDOW class. Dwm uses the DWMWINDOW class. |
So uh...something interesting just popped up in the Windows Insider patch notes for build 26040: An updated setup UI. New UI, but same old window frames. Sound familiar? Revising the visual style to address this would both improve the new Windows Setup UI and resolve this long-standing MDI problem (which isn't even exclusive to WinForms, might I add). So, with all that in mind...anyone know if the folks working on those parts of Windows even realize this is about as good a time as any to kill two birds with one stone? |
While they're at it they should also update the windows 7 control glyphs that are still in there... 🤔 |
This issue has been moved from a ticket on Developer Community.
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 text was updated successfully, but these errors were encountered: