Modernizing .NETpad: Hitting the WPF Wall (Update: Solved) (Premium)

UPDATE: After experimenting with various workarounds for the problems described in this article, I figured out a solution. There's a brief description at the bottom of the post. --Paul

--

The WPF version of .NETpad has always been my favorite, but the limitations of this app framework continue to frustrate. In my initial go-round, I ran into strange instances in which Windows Forms, an older and less sophisticated app framework, had OS integration features that WPF lacked. And I was curious to see whether that situation had in any way improved.

It has not.

And while I wasn't consciously putting this off, it's likely that my unconscious knew what my brain refused to acknowledge: I was always going to run into a wall. That it's the same wall as before is oddly unsettling.

So what's this wall I speak of? It's that WPF still inexplicably doesn't support some common and decades-old Windows user interfaces. The worst omissions are specific window types, many of which might be characterized as dialog boxes, or just dialogs. And even when WPF does support these dialogs, they haven't (yet?) been updated to support Windows 11 theming.

I first ran into this problem when I created my first version of .NETpad using WPF in late 2019 (publicly, in early 2020). WPF and its XAML UI capabilities made short work of most of the controls and interfaces required by the main app window, which looks and works like a normal window that supports resizing and includes standard menu, text box, and status bar controls. But WPF didn't offer a way to easily or elegantly interact with or customize the title bar. And when it came to secondary app windows, WPF was frustratingly limited.

That version of the app uses several sub-windows—an About box, a Fonts dialog, Message boxes for confirming choices, Open and Save as dialogs, and Input boxes for Find, Find/Replace, and Go To line. And WPF only natively supported Message boxes and Open/Save as dialogs. So I had to do what all WPF developers have done over the years and create custom dialogs and windows of my own.

Developers who love WPF will tell you that this is a strength of the framework, that thanks to its deep support for styles and themes, one can recreate any interface that's needed with a bit of work. Indeed, these capabilities are what make Microsoft's current WPF modernization work possible: The company is creating skins that make its built-in controls look native in Windows 11 (and, to some degree, in Windows 10 as well; more on that later).

Great. I love that it works at all. But what Microsoft hasn't done, ever, is address the many necessary UIs that WPF doesn't support. It doesn't matter what happened when, but the short version is that WPF arrived alongside Windows Vista, was updated with a few Windows 7-era interfaces, and then was ignored entirely during the Windows 8, Windows 10, and Windows 11 years. So it's been roughly 15 years since anyone in a position of decision-making...