The WPF Files: Fun with Fonts (Premium)

I’ve learned a lot in porting .NETpad, if partly, to the Windows Presentation Foundation (WPF) and Universal Windows Platform (UWP). Key among that learning is that my original decision to develop this application using Windows Forms was the right choice: WinForms was expressly designed for this type of classic desktop application.

WPF and UWP, by comparison, include many modern improvements over WinForms, and their similar approaches to supporting dynamic layouts, high-DPI displays, and display scaling are particularly well-done. Indeed, WPF and UWP share a nearly-identical declarative approach to application design via XAML that I find very, very compelling. But it’s equally clear that Microsoft also simply ignored vast swathes of functionality that many developers would need. And that in doing so, it severely handicapped WPF and UWP.

There are many examples of this in both frameworks. As I wrote in What I’ve Learned About C#, Visual Basic, Windows Forms, XAML, and WPF (Premium), Microsoft completely changed how developers access fonts in WPF, making it nearly impossible to use the classic Font dialog that was so easily available from Windows Forms. In fact, it was so easy to display and use this dialog, that it just required one line of code in the original (VB) version of .NETpad:
TextBox1.Font = FontDialog1.Font
That’s it. Not only can you display the standard system Font dialog, which provides such niceties as formatting each font in the list using those fonts so you can see what they look like, but pulling all of the configuration changes that the user selected simply requires passing along one simple (Font) object. It is the epitome of why Windows Forms is so special, because you can get so much done with no code or with very little code.

In WPF (and in UWP), the Font object has been replaced by separate FontFamily, FontSize, FontWeight, FontStyle, and FontStretch objects. And you cannot “map” properties of the WinForms Font object to these new objects, either easily or at all. If you use WPF with the .NET Framework, you can at least add a reference to Windows Forms, which will give you access to that Font object. But then you have to handle moving between the Font object and the new WPF objects. It’s a mess.

But if you use WPF with .NET Core, as I’m now doing in my second pass at a WPF version of .NETpad, you can’t even do that: .NET Core is not compatible with Windows Forms, at least not yet, so its objects are unavailable to you. And that means that if you want to work with fonts, you are on your own.

What does it mean to be on your own?

It means that you will need to build your own Font dialog or find a third-party alternative online. And since most of those alternatives are part of bigger sets of control packages from vendors that charge upwards of $1000 for the privilege of using their products, doing the latter is expensive. Unfortunately, doing the form manually is incredibly time-consu...