.NETpad 2025: More Data Binding, GitHub, File Operations, More (Premium)

If only there were a term that meant doing the same thing over and over and expecting different results. Because that's what it feels like I'm doing, solving the same problems again and again.

This isn't what I wanted. But as my .NETpad modernization efforts hit a brick wall, I had to confront two inconvenient truths. My inability to successfully and consistently implement data binding is a serious problem in an app that supports multiple documents. And the Windows Presentation Foundation (WPF) is not up to the task regardless. These aren't just setbacks, they're work stoppages. Fixing each requires a lot of time that I don't have and effort that is more frustrating than rewarding.

I have at least made progress in both areas.

In the previous article in this series, .NETpad 2025: Data Binding First Steps (Premium), I described how I finally got a basic bit of data binding to work and then went through the crucial process of actually duplicating that success in a new version of the app. Like so much in WPF (and the Windows App SDK/WinUI 3, for that matter), this simplest of implementations requires a mountain of code, in both XAML and C#, and this explosion of code was already an issue I was wrestling with. Now it's worse.

In that article, I also described my first steps recreating a basic version of .NETpad in the Windows App SDK/WinUI 3 (which I'll now just refer to as WinUI 3). WinUI 3 has many of the same problems as WPF, but it also has some key improvements that make it increasingly obvious that this is my only option if I'm serious about modernizing this app. There are obvious things like full support for modern controls that are core to this app (TabView and TabViewItem). And less obvious things like events that fire before a change is made, something I tried in vain to find in WPF and then workaround when I discovered this isn't a feature of that framework, despite the obvious need. But whatever. WinUI 3 is the more modern framework, flaws and all.

When I wrote that previous article, I had reimplemented the FileName property in my Documents class as a dependency property with an OnPropertyChanged() event so that it could be used with data binding. And then I bound the Header property of the first (and, for now, only) tab (TabViewItem) to that property, using C# code. This meant that I could open a new document (and, later, save a new file or save an existing document with a new name) and have that tab header automatically update with the correct file name. I also wrote a value converter so that it would display correctly, meaning, in this case, without a file extension (.txt). This worked, still does, but it required a mountain of code and all it does is one little thing.

Here's what I've done since then.
☁️ It's on GitHub
I posted this new WinUI-based version of .NETpad, imaginatively named WinUIpad, to GitHub over the weekend and have updated it a few times since then. You can find the WinUIpad repository there...