The WPF Files: Mission Accomplished (Premium)

The WPF version of .NETpad is now complete, in the sense that it duplicates the functionality of its WinForms predecessors while leveraging some key advantages and differences in this newer framework.

I created this version of the application differently than I did with the first one, which was based on Visual Basic, Windows Forms, and the .NET Framework. Instead of creating it in real-time, and documenting my progress as I went, I instead created the entire application first, and only wrote about how I did it vaguely and towards the end of the process.

That, plus my previous experience on the initial version of the app (and my C# port of that first version) enabled me to move much more quickly: I didn’t spend nearly as much time on this new version of .NETpad—which is built on C#, the Windows Presentation Foundation, and .NET Core 3–as I did on the initial Windows Forms versions. I also have absolutely not mastered the unique capabilities and complexities of WPF; this is a very complex environment.

For those who were hoping to follow along as I built this app, as they perhaps did with the initial WinForms version of .NETpad, my apologies. I may do that now, and basically recreate the app while documenting its creation here on the site, assuming there is enough interest. Otherwise, I’ll just move on to the UWP version.

In the handful of posts I did write about this project, I described my love of XAML, the XML-based declarative user interface technology that Microsoft still uses today in more modern frameworks. And wrote about how XAML makes it somewhat trivial—well, at least much easier—to create well-made custom dialogs and windows, a capability that was a struggle with WinForms.

I also wrote about what I now consider to be WPF’s biggest problem, especially when you consider that this framework was created to make desktop applications: Some things that were very easy in WinForms are comically difficult in WPF. Adding keyboard shortcuts to menu items (in my case, but to whatever user interfaces controls) is insanely and stupidly difficult, for example. This is criminally dumb, and while I know there are developers who have figured this out and will defend it, I’m sorry. But this is braindead.

Don’t get me wrong. The idea is solid. It’s the implementation that sucks, as does the fact that there are several ways to do the same thing. The short version is that WPF supports something called commands. There are built-in commands related to commonly-needed functionality, things like Cut, Copy, and Paste, but also less obvious things like navigation (WPF was designed to bring web-like interfaces to native apps), media playback and control, and more. If you can’t find a built-in command that meets a certain need, you can, of course, create a custom command. And that’s where things get really hairy.

Commands have many advantages, of course. For example, you can reference the code for a single command from multiple places—a menu item, a toolbar or ribbon button, and a keyboard shortcut, let’s say–very easily in both XAML and C# code. That’s a nice convenience, but I don’t feel that it’s much more elegant than tying a keyboard shortcut to a menu item in the designer, as you can with WinForms, and then calling that menu item’s Click event handler from the related toolbar/ribbon button’s Click event handler. That accomplishes the same thing, it’s very readable and discoverable, and it’s not complex.

Commands also support the notion of what I think of as activation. For example, if you bind the Copy command to the Edit > Copy menu item, that menu item will be automatically and visibly disabled in the menu unless it is actually possible to use that command; at that point, it becomes activated, meaning that it’s visibly choosable and the underlying functionality now works. That is very powerful, and doing something similar would require a lot of code in WinForms (or WPF, too, if you didn’t use commands). In fact, I didn’t even bother in the WinForms version of this app: All of the menu items are just enabled all the time, whether it makes sense or not.

There’s a lot more to it, but hopefully, that gives you a taste. The problems occur when it comes to implementing commands, especially when you move beyond the built-in commands, which happens very quickly, even in an application as simple as .NETpad. My final major task in completing this application over the weekend was converting several of my menu item Click event handlers into commands so that the associated keyboard shortcuts (like CTRL + G for Edit > Go To) would work.

This is an area where WPF books and even Google come up short, at least for me. I found no quick template for creating custom commands that was easily discovered and remembered, and just works all the time. Instead, I handled commands/keyboard shortcuts using multiple methods. It’s a mess—again, this was always going to be a quick and dirty project—but it works. And that speaks to my earlier comment about not really mastering WPF. I don’t honestly understand how some of this stuff works. But it’s so esoteric I almost don’t care.

If I seem to be complaining about WPF a lot, that’s because I spent—or wasted—far too much time on the difficult bits. But there were good experiences, too. In addition to XAML, Microsoft clearly got the memo on how stupid difficult that printing was in WinForms, and that was dramatically improved in WPF. (I opted to remove the Page Setup dialog from this version of the application because I’d have to use the WinForms version, and I wanted to be as true to WPF as possible; and because most of the important printing configuration changes are available via the Print dialog, which WPF does provide access to.) Some controls are much improved, including even the TextBox, which automatically handles its scrollbars better, among other things. WPF handles resolution and display scaling changes much better than WinForms. And much more.

Anyway. It’s done. As done as it can be in a few weeks of work.

So let me know if it’s worth documenting how to create the WPF version of .NETpad. If it’s not, I’ll provide the source code somewhere/somehow and just move on.