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 com...