WinUIpad: We Can Rebuild It ⭐

Armed with an AI-built version of my app that supports multiple documents/tabs, I set out to rebuild WinUIpad myself to see what I got right, what I got wrong, and what I had never thought of in my previous attempts. There was a bit of each, as it turns out.

I started with rebuilding the UI. But after going down the path outlined below, I realized I should have started with the lower-level architecture instead. That's fine, you live and you learn. And in this case, I had a welcome surprise waiting for me.

But first things first.
Basic app layout
One of the things I was curious about given my experiences trying this in different ways was how the Clairvoyance-created version of my app handled multiple documents and tabs. There are two basic approaches:

You dynamically create each tab and that tab "contains" or is somehow associated with its own dynamically created TextBox.
You maintain state for each document but reuse the same TextBox for every tab/document and manage what it displays based on which tab is selected.

The first approach is clearly more ideal, but implementing that was complicated by the fact that there is a MenuBar between the tabs and the TextBox. Would I need to also dynamically create every single menu item each time the user opened a new tab? That seemed resource-intensive.

To find out which approach Clairvoyance chose, I created a new WinUI 3 project in Visual Studio and then opened the previous (single document) version of WinUIpad and the (Clairvoyance-made) TabPad projects in separate instances of Visual Studio. Because my app's UI is cleaner than what Clairvoyance made, I started with the XAML code for that app and blocked out the basic structure of the new app, copying and pasting between my app and the new app as needed.
Basic app layout in XAML
The basic app layout is not complicated, and it's the same as before:

Then, I pulled in my stylized "T" logo as a graphical asset and added that to the upper-left of the app in the first row (Row 0, which will be the title bar/tab area). And then I added a second row (Row 1) for the menu system, though I just kept it to a single empty File menu item for now.

Compiling and running the app, I could see the logo and the File menu item, but the rest of the app window was, of course, empty.

And then it was time to see what Clairvoyance had done.

For the tabs, Clairvoyance put a TabView control in the first row (Row 0), so I added an empty version to start. You can see it, really, when it runs the app, but that makes sense.

For the TextBox, Clairvoyance had indeed gone the dynamic route. This is interesting (to me) because it also "hard-coded" the menu between the tabs and the TextBox(es), each of which it dynamically creates. So I was super-curious how that was going to work. But for now, I just added an empty grid similar to what I saw for that row (Row 3, with Row 2 somehow taken up by some Find/Replace functionality that...