WinUIpad: (Just Like) Starting Over ⭐

I’ve spent more time than I even want to think about trying to make the WinUI 3 version of .NETpad work. Worse, I’ve spent more time writing words about this effort that you will never read. So I will be as concise here as possible. For you and for me.

It’s been over two months since I published an update about .NETpad. That’s not tied to a lack of interest or because I’ve given up on the project. It’s because the Windows App SDK/WinUI 3 is ridiculously difficult and functionally lacking, both of which work in concert to make this environment frustrating. And because of my own personal failings, not just my inexperience as a programmer but also me taking on too many different things in this project at once. I’ve been trying to learn data binding, the ridiculous nuances of the Windows App SDK/WinUI 3, and whatever else on the fly, and these things take time. So that’s on me.

I’ve restarted .NETpad as a coding project more times than I can count, and since the shift to Windows App SDK/WinUI 3, I’ve run into more issues recreating basic functionality that I had solved long ago in other frameworks, often multiple times. And that prevents me from making forward progress. Which was sort of the point, when you think about it.

Looking past my own issues, the problem I see here is two-fold. First, Windows App SDK/WinUI is just different from previous frameworks like WPF, despite some surface similarities. But it’s also broken in some ways that I find troubling, and I’m reasonably sure that no fixes are incoming now or in the future.

Everyone is familiar with the phrase, It’s not you, it’s me. But in this case, I’m comfortable stating that it’s not just you, Windows App SDK/WinUI 3, it’s also me. And that while I like to identify a problem as much as anyone, I am even more interested in solving that problem.

And the way I am going to do that in this case is, yes, to start over again. Not entirely, of course, as I can bridge the gap between refactoring and a complete rewrite easily enough and bring in the code that has been working great and rewrite the bits that have been problematic. And in working on this latest reset over the past few days, I’m pleased to say that it is coming together quickly for a change.

Introducing WinUIpad

I’ve been toying with the name WinUIpad since I started reworking .NETpad with the Windows App SDK/WinUI 3, but now it’s official, and I will use that name going forward. I see there being two versions of this app, over time.

The initial version of WinUIpad will be a basic Notepad-style app that supports a single document, and I will bring forward those classes and data bindings that work and ignore those that do not. Once the basics are complete, I will try to shore up the bits that are less sophisticated. But, honestly, I feel like it will be in pretty good shape, all things considered.

The second version of WinUIpad will support multiple tabs and documents, in keeping with what I’ve been trying but failing to do throughout most of this year with .NETpad with the Modernizing .NETpad (2025) series. Despite the many issues with the Windows App SDK/WinUI 3, I do feel this environment is better suited for that work than WPF.

This is likely a year-long exercise overall. But I hope to pull the single document version together pretty quickly. He says, as if he hadn’t just wasted months not being able to make this app work.

Back to basics

Because I was stuck on data binding errors tied to the status bar and word wrap, as per the previous article, my initial thought was to simply pull those bits out of the app version I had been working on. But in doing that, I realized that there was just too much complexity in that code base, and that the easier route would be to create a new project in Visual Studio (I’m using Visual Studio Insiders now, which is a very nice update) and work my way through the individual parts of the app one-by-one, copying and paste code as needed, and rewriting as needed.

Those parts are:

• Main app window, which has the familiar four row design with a title bar area, menu bar/Settings button, text box, and status bar from top to bottom and a hidden full-window Settings interface that appears when needed (and replaces the main app view).
• Application settings (Settings.settings) to persist user-configured settings like the font, theme, window size and position, and so on.
• AppSettings class for all the settings-related code.
• FileOperations class for all the file new, open, save, save as, and related code.
• Document class for all the properties, methods, and associated data bindings for the current document, which will evolve later to support multiple documents.

So … not too different from what I had before, though the move to the Windows App SDK/WinUI previously helped me eliminate several custom dialogs I had had to create myself in the WPF versions of .NETpad. And now I will be using the system ContentDialog for the find, find previous, find next, replace/replace all features, too, which eliminates even more custom code (and wasted time). Actually, that bit is pretty cool.

It’s already on GitHub

For this version of the app, I’m finally doing something I’ve wanted to do for a long time: I put the code on GitHub before publishing this article. This lets anyone who is interested in this project see where things are at all, follow along as I update the app, and perhaps provide feedback. And for me, it’s a nice demonstration of this not just being talk. The code is real, and while it’s not done per se, the app works and most of it is there already.

You can find the WinUIpad project here.

Next steps

The basics are all there in the current version of the app, and most of the core features around file handling and so on seem to work well. But there are several features that don’t work properly or at all and some truly inelegant code that I’m not proud of. A rough to-do list for this version of the app starts with:

Fonts. My Fonts code was working fine, but when I pulled it into this version of the app, it stopped working, meaning that you can configure font attributes like font name/family, size, and so on in the settings interface, but the changes are not applied to the text in the text box. I feel like this is easily solvable, as I must have just missed something.

App exit. The File > Exit menu item isn’t implemented, and the code that runs when the app window closes is just the basics. There’s just more to do here.

Go to. The Go to feature doesn’t work at all. I’m not sure if I had tried to make this work in WinUIpad yet, but it worked fine in .NETpad so I will figure that out.

Zoom. The zoom capabilities haven’t been added yet.

Status bar updates. The Position, Character/Word count, and Zoom level displays in the status bar haven’t been implemented yet, so they’re just static text for now.

Printing. The Page Setup and Print code is missing.

Status bar and Word wrap toggles. I have struggled more with these very basic features than I care to admit, but to get these to work I first removed any data bindings and then just implemented different event handlers for each feature’s respective menu item and toggle switch, so there is code redundancy. I will fix this. I swear to God, it’s driving me nuts.

Spell check, Autocorrect. Neither of these settings is implemented yet.

More soon.