WinUIpad: Wrapping Up ⭐

Today, I fixed the two major outstanding bugs in WinUIpad, so it’s time to wrap up this project … for now.

I will definitely revisit this project in the future. There are some fit and finish changes I need to continue thinking about. And perhaps there will be a future focus month when I work on adding the AI-based writing features we see in Notepad. But for now, it’s time to move on.

Bug fix: Closing one app window closes all app windows

This bug predates my use of Clairvoyance AI to get multiple tabs/documents working: If you had two or more instances of WinUIpad running and closed one of them, it would close all the app instances. I figured I’d be able to fix this, perhaps by maintaining a count of the app instances. But then I looked at the code and realized the fix would be even simpler.

Because there are multiple ways to close the app/window, there’s a TryExitAsync() helper method that’s called by all of them (like the ExitMenuClick() event handler that runs when the user clicks File > Exit). This method tries to close each tab in the current window and, if it succeeds, it calls SaveSession() to save the app session state and then SaveWindowSettings() to save the user settings. And then it called this:

Application.Current.Exit();

And that, clearly, was why all app instances would close: It wasn’t closing the window, it was closing the app, including all app windows (and/or instances). The Windows App SDK is problematic, but I was positive it would have a Window.Close() method, and it does. And so I figured there must be some reason I wasn’t using that.

But there wasn’t. Instead, Window.Close() works as it should. If there are other app windows open, it just closes that window. If there are no other app windows open, it closes the app too. Could it really be this easy? I replaced the line of code noted above with the following to find out:

Close();

And sure enough, it works. I have no idea why this was like it was before, but I believe it’s fixed.

Bug fix: A newly opened document is marked as having unsaved changes

This bug was introduced somewhere in the Clairvoyance AI-based updates: When you opened a document, it would appear in the editor, but then the “unsaved changes” indicator would appear next to the filename in the tab. Since you just opened a document, it hasn’t been changed in any way, and so that indicator should not appear at that time.

This one was a lot less obvious.

The code in the OpenMenu_Click() event handler runs when the user opens a document. There’s a lot of code in there because there are two ways in which a document could open—in the current tab or in a different tab—but both blocks of code correctly set the IsModified property of the document object instance to false. So the issue had to be somewhere else. And there were two candidates, since the UpdateStatusBar() and UpdateRecentFilesMenu() methods are both called from OpenMenu_Click().

So I started with UpdateStatusBar(). There was nothing in there, which makes sense, but it also calls UpdatePosition() and UpdateCount(). Neither of which does anything to impact the IsModified property.

On to UpdateRecentFilesMenu(). This one is thorny too, and it calls other methods that call other methods, but ultimately, it’s just about updating the Files > Recent files menu and shouldn’t impact the IsModified property. Hm.

Obviously, some actual debugging was in order. But then I had a thought.

This is one of the code blocks that sets the IsModified property (and other document object instance properties) before calling UpdateStatusBar().

What would happen, I thought, if the data.Document.IsModified = false; line occurred after the call to UpdateStatusBar()?

Well. It turns out that this change fixed the problem. So it was something related to UpdateStatusBar()? Hm. That didn’t seem right. But …

Back to the drawing board. Or, really, the debugger. I set a break point on the OpenMenu_Click() event handler and then stepped through the code that ran when I tried to open a document. And sure enough, I found it. Because loading the document into the editor (the text box) changes its contents, an event handler runs and that changes the state of IsModified. So moving that line of code so that it sets IsModified to false after that change makes sense. My silly little fix actually works. In fact, it only has to occur after the text in the editor changes: UpdateStatusBar() has nothing to do with it.

Sometimes, simpler really is better.

A few fit and finish updates

Update: After posting this late yesterday, I made some fit and finish updates to the app and project:

• The toggle switches on the settings page are positioned better visually
• The app icon is now correct
• Updated .NET from version 8.0 to 10.0
• Updated target/supported OS to Windows 11 version 24H2+

The code is on GitHub

These code changes are available in my WinUIpad-2026-Tabs-version repository on GitHub, so you can check out the finished (for now) app for yourself.