.NETpad 2025: Thinking About Layout (Premium)

I've made remarkable progress on the important, low-level code to manage multiple tabs and documents in .NETpad. But there are many problems, too. Key among them is my lack of sophistication when it comes to harnessing some key WPF innovations, like data binding and the MVVM design pattern, which would make this implementation more sophisticated and manageable. I think so, anyway. I haven't figured out any of that yet.

So I plow forward, dividing my time between raw work and what I think of as research and experimentation, during which I try to grok how I can use those elusive WPF capabilities. In doing so, I've confronted my technical limitations again and again. It's uncomfortable. Sometimes, I return to a complex block of code--that ... does something--that I wrote and have stared at it for long seconds trying to understand it again. This work requires peak brain power, and it's just not always there.

Which is why I took a break the other day, opened Notion, and looked at my .NETpad to-do list for 2025. Perhaps there was a smaller task I could take on, an intermezzo of sorts, that would be easier on my brain and give me a needed win, even if it was a small one. The result was the partial solution to the custom dialog resizing issue I wrote about this past week. I checked that one off the to-do list, though I also added a sub-to-do, "Try to fix the mouse cursor issue too." One step forward, one step back.

That's OK, I needed it. But making that change also required me to go back to the public source code for .NETpad 3.0 for Windows 11, which is available to everyone on GitHub. The version of the app I'm working on now (I suppose I'll eventually call it .NETpad 4.0 or whatever) is a different beast entirely. It's much more complex. Much more.

It may be too complex. Seeing the cleaner, simpler .NETpad 3.0 code again was eye-opening in its own way. There are many problems with this code, don't get me wrong, and I am eager to fix them. (Some of the changes I've been making so far this year actually do address issues, go figure.) But compared to what I'm doing now, that code is simple and easily understood. I miss it.

So maybe this was a wake-up call of sorts. I feel pretty good about some of the work I've done, conceptually, related to managing multiple tabs and the associated documents and state. I create TabItem controls dynamically, in C# code, and can open and close them arbitrarily, and it basically just works. I'm happy with a lot of it. But it is, by nature, a mess, too. It's early days. I'm figuring it out.

Seeing the public source code again at least inspired me to take a step back and think about some of the other issues I will need to address. And some of those issues are tied to layout. That is, the app has to support one or more tabs. There can be any number of tabs. As the user adds new tabs, and closes tabs, all the tabs should resize if needed to accommodate the width of the app window. This needs to happen in...