The WPF Files: A Few Successes (Premium)

The other day, I complained about how WPF (and UWP) make it difficult to do things that were easy in Windows Forms. But it’s not all bad. In fact, there are several niceties in both of these more modern frameworks that I really appreciate. I just wish Microsoft hadn’t dropped so much of what was good about WinForms.

So today, I’ll focus on the positive. This includes some of the improvements in WPF as well as some of my own mini-successes in porting .NETpad to this confusing (to me) environment. I’m glad I started with WinForms, and with Visual Basic, too, since that collective environment was at least familiar to me, and that collectively helped me get up and running more quickly than would have been the case had I started off with C#, which is a more powerful but complex language, and with WPF or UWP, which have their advantages but are likewise confusing. Again, to me.

And that’s the thing. As I promised early on in my work with .NETpad, I can’t teach you programming because I’m learning as I go myself. I make mistakes, and I have to backtrack when I head off in the wrong direction.

Case in point: I’ve struggled on separate occasions for what seems like weeks to get WPF to interact with the FontDialog and Font objects/classes from Windows Forms that provide simple and easy access to the system Font dialog and thus to the available fonts on the PC. This is a bit hard to explain, but I was able to get it (sort of) working when I created a C#/WPF/.NET Framework version of the app. But when I switched to .NET Core, Windows Forms---and thus its FontDialog and Font objects/classes---were no longer available.

So I experimented. As I did earlier when I started trying to manually implement something like a Task Dialog in Windows Forms, I eventually decided to roll my own Font dialog, frustrated that WPF didn’t provide its own modern equivalent and that the WinForms FontDialog was no longer available when using .NET Core.

Then a reader, davidl, jumped in to help in the comments of the previous article, explaining how you could make this work: This isn’t documented by Microsoft to my knowledge, but with a simple workaround, you can access Windows Forms and its objects and classes in a .NET Core-based Visual Studio project. Nice. And thanks again to that reader for the help.

Yesterday, I set out to yank out my own Font dialog and replace it with my homemade version. And what I arrived at was the same place I had been previously when I was still using the .NET Framework. It only sort-of works. That is, yes, I can pull up the Font dialog and then apply the font changes back to the app’s textbox (and then later save those settings when the app closes so they’re available at the next run). But pulling the font information from the text box and auto-configuring the Font dialog to use the right font name, style, and size was problematic. Because, again, WPF uses different objects to represent fonts than does WinF...