The WinForms Notepad Project: What’s Next? (Premium)

It’s time to think about what’s next for .NETpad, a project I had originally hoped to finish up by the end of 2019. But I don’t mind that it’s kept me busier for longer than I expected. That simply means that we were able to duplicate (or at least approximate) far more of Notepad’s functionality than I originally thought was possible.

And to be clear, it was definitely “we” and not “me.” There is functionality I’m not sure I’d have ever figured out, like Find, Find Next, and Find Previous, and Replace and Replace All, all of which is credited to reader Michael Lerch. And printing, which was solved almost 20 years ago by programming legend Charles Petzold. And then dozens of smaller issues that were found by readers.

Obviously, I wish I could have figured this all out on my own, but I’m glad for the interaction and the help, and I recognize my limitations as a would-be developer. If you think back to my original post in this series, I noted that I wouldn’t be teaching you how Visual Basic or any programming language works. But as many of you probably realized even then, I had hoped that we might learn together. That in teaching myself how Visual Basic.NET, Windows Forms, and the .NET Framework might be used to create a recognizable Windows application, at least some of you would follow along and learn something in the process as well.

I sometimes write about the many side projects I’ve created at different points in this series to isolate a problem and find something that works. And I’ve created dozens and dozens of them, some of which did indeed lead to specific functionality in .NETpad. But there are others that led to dead-ends. My various attempts at understanding how printing works in Windows Forms, for example, or the several projects aimed at understanding text file encoding (which is very much broken in Windows Forms/.NET, and possibly just in general because of the differences between how Windows and other platforms handle this.)

One thing I also did fairly recently and over two or three days was to go back through the series and attempt to use my articles to recreate .NETpad from scratch. That was pleasant because it worked great, and I felt like the instructions were mostly pretty clear. I won’t ever do this, in part because Windows Forms is so old-fashioned now, but I could see transforming this into a project-based book or perhaps part of such a book. It was actually pretty fun to go through it.

I’ve also started making a new version of the project in C#, Microsoft’s much more popular and syntactically complex programming language. This is a bit hard to explain, but it’s very clear that Visual Studio’s support for C# is more advanced than that for Visual Basic, and it has prompted me with a plethora of warnings that I never see for the similar code in VB. That is a challenge in its own right, and while I feel that C# has a more obvious future and is thus perhaps the “better” language to learn, VB is equally obviously the better choice for the beginner. It reads like plain English and is, I think, very easy to understand.

So. What’s left?

Looking at the state of .NETpad today, I see the following areas for improvement.

File encoding and line ending support. As noted above, this is basically broken and could be impossible to do properly in Windows Forms. I can’t differentiate between ANSI and UTF-8 encoding, for example. What’s interesting is that I’ve discovered that Notepad’s support for this is also broken and it can misrepresent the encoding of various text file types. And there’s the issue in a nutshell. This is a problem generally, and the likelihood of getting it to work is nearly zero. So I will simply ignore it.

Localization. .NETpad is hard-coded for U.S. English, meaning that all of the text in the application—the menu names, the text you see in dialogs and elsewhere, is all displayed in that one language, no matter where you live or how you’ve configured Windows. Ideally, the application would support multiple languages, and I’ve been investigating how hard it would be to transform .NETpad. Ideally, we would have done this from the beginning. But I’m a beginner, and that’s on me. (Well, partially. Had I started with C#, Visual Studio would have warned me about this immediately.) I would like to make this happen.

Implement Find, Find Next, Find Previous, Replace, and Replace All properly. These commands currently work, but because Windows Forms doesn’t provide the system Find and Replace dialogs that the real Notepad uses, that will require tons of work. I’m honestly not sure if it’s worth it, and I vaguely enjoy that the name of the project, .NETpad, maps to what it can do: It literally is Notepad but implemented using .NET. And since .NET doesn’t provide access to the system Find and Replace dialogs, we had to find a workaround.

WordWrap bug. There is a major problem with Word Wrap, and this was the original impetus for me recreating the project from scratch: I was worried that I had introduced a bug later on in the process. But the more I look at this, the more I believe that Word Wrap (in Visual Basic.NET/Windows Forms/.NET or whatever) is simply broken. Sometimes you set it and nothing changed. But you restart the app and it’s working the way it should. I am looking into whether this is the case with C#, and whether switching to a RichTextBox would “fix” this issue too. Speaking of which…

Rich text support. Swapping out the TextBox control for a RichTextBox control at this late stage in the game would probably be prohibitively painful. But I have been experimenting with RichTextBox on the side as well and think a version of this app that supported rich text would also be interesting.

Fluent effects. I mentioned in the past that I was interested in seeing whether Microsoft’s decision to support UWP capabilities like Fluent could someday impact .NETpad, and the most obvious thing I’d like to add is the Fluent transparency effect as a configurable option. This is complicated, and is still in pre-release, and it would be easier if I was using C#. But it’s something I’ll keep looking at.

.NET Core. .NETpad is written to the latest version of the classic .NET Framework, but Microsoft is moving to .NET Core (which will become .NET 5.0 sometime in the next year), which offers various advantages. The biggest for our app would be the ability to bundle the runtime with the app so that the user doesn’t have to separately install the .NET Framework. Right now, .NET Core doesn’t support Visual Basic for desktop applications, but I’ll be looking to see when and how I can make this switch as the platform improves.

Fit and finish. Of course, there are still many bugs in .NETpad, and many other small coding improvements that can be made. The status bar needs to be cleaned up, and I would like to implement some kind of a “thank you” dialog or whatever to recognize those that helped make this all come together. I’ll probably take a pass at these smaller tasks before moving forward with anything major.

More soon.