.NETpad 2025: Tabs Next Steps (Premium)

The way that WPF implements tabs is old-fashioned, non-optimal, and in no way ideal for .NETpad. But I'm going to try to use it anyway. In this post, I will highlight the problems I face and discuss the progress I've made.

Basically, a brain dump. Apologies.

If you're interested in this topic, and God help us all, it consumes me sometimes, then it's worth reading .NETpad 2025: Tabs First Steps (Premium) if you haven't. The short version is that I need to dynamically create tabs--TabItem controls in WPF-speak--using C# code. And this is complicated because the tabs I'm creating are what I think of as complex or compound tabs in which their constituent parts--the header that displays the document name and the content--can both be implemented using a grid of multiple controls.

In the previous article linked above, I described only the creation of the TabItem header in C#, which is successful enough. But there's more to this. I have to programmatically access the header of any tab at runtime--such as when the user closes a tab, creates a new tab, opens a new document, and so on. And I have to figure out the content, by which I mean that I may not even need it. As this progresses, I'll decide one way or the other.

Another complication: The layout used to display the Notepad main window--and thus for .NETpad as well--may dictate whether I can use TabItem content at all (or normally, as you'll see in a moment). That is, because of the dated natural of the TabControl and TabItem controls in WPF, which, again, were designed for the world of 20 years ago, not 2025, and were never updated in a meaningful way. They're better suited for static, old-fashioned user interfaces in which the TabControl is visually a container for two sets of controls, the header on the top and the content on the bottom.

But Notepad doesn't use this design. In Notepad, the tabs and the content--the text box that takes up most of the space in the app window--are separated by a menu bar. So there are (at least) two choices here. I could ...

Make the content a Grid that also contains the menu bar (i.e. it would contain the menu bar and the text box)
Use only the header--which is a Grid with a document title and a Close tab button--and ignore the TabItem content, and just lay out the menu bar and text box (and status bar and whatever else) outside the TabControl. I can maintain the document in each tab--i.e. what you see in TextBox1, the main app window's text box)--using DocumentTab.

I implemented basic versions of both designs. But for all kinds of reasons, I have to use option number two. Reimplementing the menu bar for every single tab is stupid. But I also omitted an important bit: I also put a Find/Replace bar between the menu bar and text box, one that's hidden by default. There's just too much UI in there to do that, all inside a dynamically created TabItem. So I will ignore the TabItem content.

Except that I won't. Maybe. I don't know.

I...