The WinForms Notepad Project (2022): Reviving a Classic (Premium)

For my January 2022 programming project, I’m reviving the Windows Forms (WinForms) version of .NETpad so I can make it available publicly on GitHub. And then I’ll look into modernizing it as I wrote previously in .NETpad Resurrections (Premium).

As it turns out, this required more work than I had expected.

For reference, I pushed all four of my .NETpad versions—Visual Basic/WinForms/.NET Framework 4.x, C#/WinForms/.NET Framework 4.x, C#/Windows Presentation Foundation (WPF)/.NET Core 3.1, and C#/Universal Windows Platform (UWP)—to my GitHub account about a year and a half ago, intending to make them public. And then I didn’t, for no reason I can think of. I got lost in researching other programming projects, time went by, and here we are.

Flash forward to today, and things have changed more than a bit since I first started these projects. Microsoft .NET has advanced from .NET Core 3.1 to .NET 5 and then .NET 6. Incredibly, Microsoft has started updating WinForms again, despite it being a 20+-year-old technology. And Visual Studio has progressed from version 2019 to 2022.

Anyway. In reviving these projects, starting of course with the only one I didn’t document on Thurrott.com, the C#/WinForms/.NET Framework 4.x version, I discovered that each needed to be cleaned up and fixed in some way. So I obviously needed to do that work before I could make them available, in turn, to you.

I’m not a professional programmer or a Visual Studio expert, so I eventually needed help with some of the issues I was experiencing. And so I naturally turned to Rafael Rivera—who is a professional programmer and a Visual Studio expert–for the answers. As always, he’s been a godsend, and he got me over some humps that otherwise would have caused me to simply start over from scratch. I was literally going down that path when he saved the day.

I also originally wrote a rather tedious 2500-word article (over) detailing the problems I encountered while updating and fixing the C#/WinForms/.NET Framework 4.x version of .NETpad. But since you won’t need to make these changes yourself, I sat on it for several days and then ultimately decided not to bore you with it. Instead, I will quickly explain each issue and fix, in turn, here.

To get started, I installed Visual Studio 2022 Community and configured it with the workloads I will need for all of my .NETpad projects: .NET desktop development and Universal Windows Platform Development, plus Desktop development with C++ because I can’t help myself and you never know. Then, I cloned—basically, made a local copy of—the C#/WinForms/.NET Framework 4.x version of .NETpad onto my laptop in Visual Studio to see where it was at.

And then I tried to build and run it, of course. How naïve of me.

Given that .NETpad worked perfectly when I last did this, I was surprised to see that there build errors, and that at least one of these errors meant that I couldn’t even run the application. Ultimately, I had to Google the only Severe error—“Unable to find manifest signing certificate in the certificate store”—to discover the cause. And all I had to do was uncheck one option in Project Properties > Security—“Sign the ClickOnce manifests”—and the app built correctly … and triggered another warning, telling me that Visual Studio would need to disable “the security debugging option.” Clicking OK in this dialog allowed the app to run, but I obviously don’t want any of you to see that, so I Googled that one too. Turns out, I just needed to disable the option Security > “Enable OneClick security settings” in Project Properties. (That both of those issues are ClickOnce-related is interesting.)

Anyway, the app would now build and run. Unfortunately, it looked terrible.

There were three obvious visual errors that were not present when I originally pushed this project to GitHub in mid-2019:

• The app window was overly large and extended past the borders of the screen.
• Only some of the four status bar items were visible on the bottom of the app when sized normally. (See below)
• The checkboxes in the menus were not displaying correctly. (See below)

I figured all three of these problems were related to high DPI issues. After all, WinForms predates support for high-DPI displays, and while Microsoft did add support for this over time, and even improved it recently with .NET 5 and/or 6, it’s never felt as seamless as the support in WPF and UWP. And so I spent an inordinate amount of time researching this, trying various fixes, and creating quick shell WinForms apps to prove that high DPI could, in fact, work just fine. (Which it did, just not in my original app.)

Eventually, I conceded defeat and turned to Rafael for help. He quickly determined that the problem wasn’t the app’s high-DPI support (again, he’s an expert) as I had suspected (again, I am not an expert). And starting with the weird checkboxes in the menu system, he found that the MenuStrip control’s ImageScalingSize and Size property values were off. He showed me a version of the app he had cloned with the issue fixed.

Interesting. I confirmed his fix by implementing it in my own locally cloned version, but I was confused why an app that had looked and worked fine would be so off now. Rafael blamed Visual Studio and its legacy WinForms designer, noting that it appeared that they were making changes to the project on their own on first open. In short, it wasn’t my fault. (It’s also not something I’d ever figure out on my own, I bet. I was literally ready to give up.)

Armed with this information, I examined how the window was initially sized in Project Properties > Settings and discovered that the MySize setting was set to 1800, 1600, which is awfully large. And so I changed it to 1200,800. (If you resize the app while running it, it will remember that size the next time you run it; that’s what the MySize setting is for.) That solved the window size issue.

Finally, I looked at the status bar, which is implemented with a WinForms StatusStrip control. Fixing this required a lot of work, frankly, and while it’s much better now, it’s still not exactly where I want it.

Describing what I did and why is complicated. But the short version is that the StatusStrip originally contained four StatusLabel controls for displaying Auto Save, Position, Word Count, and Zoom. These were left-aligned in the status bar rather than right-aligned as in the original Notepad because I think that looks better. And they all had issues related to their ImageScalingSize and Size properties (just like the menus) as well as problems with spacing and alignment. Fixing the sizing was easy. Getting these controls to line up the way I wanted was not.

Where they’re at now is … OK. I created spacers between each StatusLabel and their divider line, which looks better. Each label is sized in such a way that they won’t move around if the content of any of the labels gets too big. For example, the Position label (which displays the text caret position label in the form of “Ln x, Col x”) can expand when the line or column value exceeds 9, 99, 999, and so on, and if the number got big enough, it would cause the control to grow horizontally, shifting the Word Count and Zoom labels to the right. Now it doesn’t.

But the labels still don’t correctly resize and then overlap if the user shrinks the window horizontally, as Notepad does. Instead, the labels just disappear in turn as the window shrinks:

This is how .NETpad always worked, to be fair: it’s just one of those things I never figured out. But perhaps I can fix that when I start working on modernizing the app.

There are other things I can’t fix, either because WinForms doesn’t support it or because I have no idea what I’m doing. For example, WinForms menus have a two-column look, where the left-most column (where a check box might appear) is shaded darker than the left-most column, where each menu item appears. The menus in Notepad do not look like this.

Speaking of menu differences, I notice that in Windows 11, at least, the Notepad menu is white and not a light gray/tan color. But this is changing soon as Notepad is getting a big visual refresh in Windows 11, so we’ll get to that. (I also can’t recall how this looked in Windows 10, but whatever. Forward to the future.)

One final little issue that’s a historical byproduct of the way I created the app in the first place. If you followed along with the original Visual Basic/WinForms/.NET Framework 4.x, you may remember that I started off using a RichTextBox control instead of a TextBox control because I mistakenly believed it included some features I’d need that TextBox did not. When readers explained my mistake, I switched to a TextBox (early on, thankfully) because the Notepad application I was emulating only works with plain text anyway. But this version of the app, the C# version, uses a RichTextBox control. Not for the above-mentioned reason, it was created later, but (I think) because I was originally planning to add a rich text option with a corresponding style toolbar. I never did—I moved on to the WPF version of the app instead—but the version you’ll be getting uses that RichTextBox. Ah well. No biggie, but worth mentioning. (And maybe that toolbar is of interest as part of the modernization.)

Anyway, it is what it is, and the app is finally in what I’ll call a semi-presentable state. (Well, hopefully. I spent so much time working on the above-mentioned issues that I’ve barely examined the source code. The app does at least work.) So now, the next step is to make this project publicly available on GitHub. I’ll get my changes pushed back to GitHub and then figure out how to do all that, most likely with more help from Rafael. (Surprise. I’m not a GitHub expert either.) Then we can start making some changes.

More soon.