The UWP Files: Be True to Your School (Premium)

After experiencing many frustrations, I had an interesting breakthrough with my Universal Windows Platform (UWP) version of .NETpad, the Notepad clone. This success mirrors an earlier and similar success I had with WPF. And coincidentally enough, it is also related to font support.

So let’s step back for a moment so I can explain what led to this.

I think most understand that we bring biases to these things we do, and that they’re based on experience and preference, but I now have two good examples of why breaking out of that rut can be liberating. When I started working with Visual Basic and Windows Forms, I was struck by how much you could get done without writing any code at all, thanks to the visual forms designer in Visual Studio, and by how similar it was to the classic VB of old. And WinForms seems ideal for classic desktop applications like a Notepad clone, even though there were frustrations about the lack of support for features both legacy (Task windows) and modern (sophisticated display scaling support, Windows 10 themes).

But thanks in part to help from some readers, I was able to “complete” .NETpad, my Notepad clone, using VB and WinForms, and I even added several useful features, including word count, auto-save, (editor) theme support, and more. I later privately ported the entire application to C# as well, in order to prepare myself for future projects.

So it was on to C# and WPF (and .NET Core 3.1, instead of the legacy .NET Framework). And I brought my biases with me, which in this case included wanting to duplicate .NETpad/Notepad as closely as possible with the newer technologies. And then I described my frustrations with some features that were present in WinForms but missing, inexplicably, in WPF, most notably a Font dialog. (And, related to this, that Microsoft had so dramatically changed how fonts work in WPF that moving back and forth between the old way of doing things and then new was quite difficult.)

A reader helped me with the non-discoverable way to use the WinForms Fonts dialog in WPF, but that latter (parenthetical) issue meant that it was still not ideal. But that’s when the mini-epiphany hit: Instead of fighting WPF and trying to make it adapt to what I wanted, I decided to embrace WPF and use some of its unique strengths—most notably its support for creating XAML-based user interfaces—instead.

In doing so, I “completed” the WPF version of .NETpad by creating three custom XAML-made dialogs—Font, About, and Input Box—and I could see spending more time and replacing all of the other system dialogs in the application with my own. But I wanted to move forward, too. And after considering both UWP and Xamarin for the next app (don’t worry, I’ll get to Xamarin too), I decided to go back to an earlier effort to port .NETpad to UWP.

But here’s the thing. Once again, I found myself in the same trap: Even while understanding that UWP is a different thing than WinForms and WPF, is fundamentally a mobile framework that was originally designed to work across multiple form factors (including not just PCs, but phones, Xbox, HoloLens, Surface Hub, and more), I still set out to make it work the way I wanted. To make a UWP version of .NETpad that will still visually and functionally a Notepad clone.

And there have been frustrations.

I struggled a bit with user settings. In WinForms and WPF, Visual Studio provides a nice visual designer for adding and managing these settings. And while it maybe wasn’t obvious at the time, this designer isn’t just a nicety, because in UWP you have to do it all in C# code. And that means you need to do lots of testing, error-checking, and accounting for different situations (like the first run) where those settings don’t yet exist. I got through this by handling just some of the settings related to fonts first.

But then, that’s why I started working on user settings in the first place: I wanted to implement that Font dialog I had created in WPF/XAML in the UWP version of the app.

When UWP was first released with Windows 10—and really, it predates that since it debuted with Windows 8 as Metro—it was designed for full-screen apps that, again, would run on multiple device types. In Windows only, I believe, these apps could run in windowed form, so they could be minimized, snapped, and manipulated in other ways. But even common actions like a user manually closing an application were frowned on. These apps were meant to work like mobile apps and have an automatic lifecycle during which they would suspend and then close on their own as needed.

So how this impacts something like a Font dialog? Well, if I had written .NETpad for UWP in 2015, I wouldn’t have been able to even make a Font dialog. Instead, Font would be a frame that took over the entire app’s user interface, and a user would navigate to and from it as needed. I actually implemented a version of this to see how it works, and to be honest, it works fine. It’s not even that weird in non-windowed (frame) mode.

If I had written .NETpad for UWP in 2015, I also wouldn’t have been able to use a normal menu: Back then, all developers had for this kind of UI was toolbar with gigantic finger-sized buttons.

But things have changed. UWP supports secondary windows now, making a Font dialog of my own creation, one that looks just like the one from the WPF version of the app, possible. It also supports traditional menus. These and other platform improvements mean that I could, technically, make a version of .NETpad in UWP that pretty closely resembles the previous versions of the app.

But in struggling with all this, with the settings and the sub-windows (called AppWindows), and in moving data back and forth, and so on, I suddenly had my UWP mini-epiphany. Which is a cheat, since it was the same basic idea I had had previously with WPF. And thus should have been obvious.

And it’s this. Instead of fighting UWP, and trying to make it adapt to what I wanted, I realized that I should embrace it and use some of its unique strengths to make an app that is truer to UWP. I came to this realization fitfully. And because my research made me realize that UWP has other UIs—flyouts, perhaps, or maybe a content dialog, or a slide-in pane of some kind—that would make this font configuration both easier and more native to UWP.

I haven’t actually explored that yet. But that’s because this “hey, dummy” realization made me look, too, at what UWP offered for providing commands to the user. Maybe an old-fashioned menu bar wasn’t the answer.

And what I came across was the evolution of that toolbar with gigantic finger-sized buttons I mentioned earlier: UWP offers a command bar that lets you use buttons, textual menus, and many other controls instead. And these days, it actually looks and feels both modern and native.

Hm.

So I took a step back and began experimenting. Could I use a command bar in place of the menu? And what about that “status bar” at the bottom, which in UWP was implemented with a stack panel and some text blocks?

Yes and yes.

It’s still early. I still have some thinking to do about primary controls (those that will appear if possible as icons on the command bar) vs. secondary controls (those that will always be in the overflow “see more” menu). But I like what I see. A rich collection of icons. Automatic keyboard shortcuts without all the commanding nonsense from the WPF version. (And flyover hints.) And the way it looks. I like the way it looks.

Please don’t quibble over the icons, etc. Again, I just made the switch. I’m still working on it. And I’m nowhere near to figuring out how I want to do the font configuration. That will come next. But it’s easy to convert from the old system to the new (and while I won’t do this, it’s even pretty easy to implement the old UI and the new UI as options).

So … let’s see where this takes me. But I like the new look, and I think it makes sense for the UWP version of the app.