Winforms: MDI child windows use hard-coded Visual Style Rendering

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

1) Create an MDI container as the main application window (typical). (Set IsMDIContainer to true)
2) 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)

[Amy-Li03]

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.

[kirsan31]

@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 :(

[RussKie]

I corrected @Amy-Li03's post to say "the same behaviour was observed".

[weltkante]

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:

[gwickman-dev]

@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.

[merriemcgaw]

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.

[merriemcgaw]

Tagging @OliaG for discussion as well.

[kirsan31]

Any news?

[GraPhiX-Guru]

Any News 2

[gwickman-dev]

Any news 3?

[kirsan31]

Guys, instead of this bumping, pls vote 👍 to the first post.

[RussKie]

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.

[PhilippKoehler]

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!