Modernizing .NETpad: The Trouble with Tabs (Premium)

When I started this year's .NETpad modernization project, it wasn't entirely clear where the new version of the app would end up. But thanks to the coming November release of .NET 9, which this requires, I at least had a rough schedule to stick to. It seemed like plenty of time. I'd figure it out.

I think I've figured it out.

That said, there's so much more to do. I'm still working on--and struggling a bit, it's the process--with the Find/Replace functionality. I haven't thought all that much about Go to line, though that feature seems comparatively simple. And then there are two remaining tasks, both major. The tabbed interface, most obviously, as it's the most important functional difference between .NETpad and Notepad. And then a less obvious but equally important need to customize the title bar, a modern app design pattern that is difficult but not impossible to do with WPF.

I've known about all these tasks from the beginning. What I wasn't sure about was whether I would be able to complete them all successfully. To find out, I've experimented. A lot. This involves standalone Visual Studio projects, each aimed at solving a particular problem. When this work is successful--my implementation of the app's new Notepad-like settings page is a great example--I've rolled it into the main app. When it's not, I keep trying. Two months into this project, and dozens of mini side projects later, I am semi-confident of two things. There's still so much more work to do. And I think I can get it all working. The tabs. And the title bar customization.

That said, November suddenly looms over me like a weight. It doesn't seem like plenty of time anymore.

I will discuss title bar customization in a future post. Here, I'm focusing instead on the tabs. The white whale. The most important modernization task of them all, really. And to do that, I have to step back a bit and discuss what this means conceptually. Getting this to work was--still is--a hurdle. A problem that needed to be worked. And I think I figured it out.

You may recall that Microsoft rearchitected its Office desktop applications at one point to implement what's called a Multi-Document Interface (MDI), as opposed to the previous interface, which was called Single Document Interface (SDI). Without debating the relative merits of these interface types, MDI and SDI are quite different, and the adoption of MDI was tied to Microsoft's object-oriented programming (OOP) push in the 1990s. (Which I documented in the Programming Windows series that became Windows Everywhere.)

Without going too far into the weed, an app with a SDI interface contains a single document. If you open another document, it replaces the document you were previously using. Otherwise, you can open a second instance of the app, and have two copies of it running side-by-side, each with its own document.

An app with an MDI interface can contain multiple documents, each in its own child window (or sub-window)...