Programming Windows: Hello Again, Windows Forms (Premium)

In researching the Longhorn-era WinFX technologies that will soon enter this story, it occurred to me that I needed to take a step back and touch on an important, related topic. And that will require another short side-trip into some source code.

As you may know, we were in Mexico recently, and I spent a lot of time during those two-plus weeks writing about and researching topics for the Programming Windows series. It’s hard not to be obsessive about this topic: the period of time I’m writing about now—the early 2000s—was the most exciting time to be a Windows enthusiast, culminating with the wild all-time high of the Longhorn reveal at PDC in October 2003.

As you might imagine, I often split my time between the topics I’m currently writing for the series and the topics that are just over the horizon. And while we were away, I started diving in and out of materials related to the Longhorn 2003 reveal. Among them, the PDC keynotes from that year and the prior two shows, from 2000 and 2001. Which I have watched, and read the transcripts from, again and again and again.

Most are likely familiar with the Bill Gates keynote from PDC 2003, where he brought out Hillel Cooperman to demonstrate the proposed Longhorn user interface. And I will certainly be writing about that, and in-depth. But fewer people are probably as familiar with the next keynote, which featured Windows lead Jim Allchin and two high-profile and influential Microsoft engineers, Don Box and Chris Anderson, who wrote Longhorn code, live, on-stage.

Riding on a bumpy bus ride from Mexico City to Puebla for a long weekend a few weeks back, I watched, mesmerized, as Box and Anderson used plain text editors, and not Visual Studio, to write their application code and then compile it from the command line. And I was reminded, instantly, by my reaction to this when it happened live in front of me. I didn’t understand what they were doing—I had pretty much stopped writing software code at the dawn of the .NET era—and I most certainly didn’t understand the declarative, XAML-based user interfaces they created. (Don’t worry, we’ll get to XAML soon enough too.)

But in the years since, I’ve become much more familiar with .NET-era technologies, including C#, XAML, and the various Windows app frameworks that Microsoft has released in the intervening 20+ years. I’ve written four versions of my .NETpad app using mostly C# (one version in Visual Basic) and the .NET Framework. And two of the four involve declarative, XAML-based user interfaces. And so watching Box and Anderson this year, with fresh eyes, I suddenly realized a few things.

First, I now understand what they were doing in a way that I did not over 20 years ago.

Second, I knew I could recreate this code, I was sure of it, using the modern and released versions of the technologies they were demonstrating publicly for the first time that day. Over time, WinFX turned into another version of the .NET Framework, and the namespace names changed, as did many of the properties and methods they contain. But I could—and I will—reproduce what they showed off that day. The details may have changed, but the broad strokes did not.

But this made me think back on Windows Forms, which I’d written about previously in this series, in Programming Windows: Windows Forms (Premium) and Programming Windows: Hello, .NET Framework and Windows Forms (Premium), the latter of which contains some simple code examples. And what I also realized was that I had most likely not done Windows Form justice. And that by ignoring a key piece of the Windows Forms puzzle, I was ignoring a very important part of Microsoft’s Windows app framework evolution.

Let me explain. Even when Windows Forms was new, most developers likely treated it as I have, as the logical successor to (classic) Visual Basic. Yes, it improved on that earlier environment in important ways: you could use C#, for example, instead of VB, and the underlying code was based on the .NET Framework, which was sophisticated and object-oriented, unlike classic VB code, which was not particularly sophisticated and was “object-based.” But it was basically the same thing. Right? You used a visual designer to build your app’s UI, and then you wrote code to handle the events that you wanted to handle, just as with classic VB.

Wrong. Or, not exactly.

Yes, you could do this. And yes, I think most developers did do that. But because Windows Forms was implemented as a discrete namespace within the .NET Framework, it was also possible to build Windows Forms entirely using C# (or VB) code. That is, you didn’t need to use the visual designer or even Visual Studio. Instead, you could create a Windows app using just code. Not just the underlying event handler code and other logic, but also the user interface.

That was exactly what Box and Anderson did at PDC 2003, but using a new-generation framework, then called WinFX, that was—like Windows Forms—built off of the .NET Framework. The difference is that WinFX was also a leap forward from Windows Forms, and in many ways. One of them being that declarative, XAML-based user interface capability.

We’ll get to that. Oh, we’ll get to that. But for now, I want to quickly examine what a developer might have done—and could still do today—if they wanted to create a Windows Forms app entirely with code, and without using the visual designer in Visual Studio. The idea here is that what Box and Anderson had done years later might have been less unfamiliar had I only understood that this was possible in the previous environment. And as I suspected while I was in Mexico, and confirmed when I got back to my book collection when I returned home, this process was, in fact, documented, and documented well, by the exact person I figured would have been all over this: Charles Petzold. That freaking genius.

In his book Programming Microsoft Windows Forms—which I purchased two and a half years ago, used, for researching this series—Mr. Petzold explains that the simplest Windows Form program is almost as easy as a basic console program, like the one I wrote in Programming Windows: Hello, .NET Framework and Windows Forms (Premium). So let’s see what that looks like.

You could create this app in different ways: using a simple text editor (like Notepad) with command-line compilation and build tools or with Visual Studio. And I did try both. But there’s a more unusual option, too: Petzold created a simple C# developer environment for this book called Key of C# that actually requires an old version of the .NET Framework. And so I used that.

The very simplest all-code Windows Forms application just creates a blank window.

Of course, this app is flawed: it passes the new form—the main and only application window—to the Application.Run() method, and because that method doesn’t return until the form is closed, there’s no way to do anything with the window, like setting its title or whatever.

So he offers up this improvement.

From here, the sky’s the limit. You can add controls—like the menu bar, text box, and status bar used by my .NETpad app—and write event handlers. As a very simple example, we might handle the event that occurs when the user clicks the main window. There are two basic steps:

1. Create an event handler method. This can be named as you like, but it must have the right arguments and return value. I cheated by looking at a blank Click event handler in Visual Studio, but if you know enough about the .NET Framework, you can look through the class hierarchy and see where this event handler is defined. It will look like so:

private void form_Click(object sender, EventArgs e)
{           

}

2. Attach the event handler to the event by specifying the object implementing the event (“form”). Like so:

form.Click += form_Click;

And then write some code in the event handler, of course. Keeping it simple, you might display a message box when the user clicks the main window.

What’s missing in Windows Forms is a way to elegantly design a form and its contained controls using only code.

For example, you can declare the basic structure of a webpage (or web app) using HTML code, style it with Cascading Style Sheets (CSS), and write code to handle events using JavaScript. With Windows Forms, the internal workings of the designer are unknown, and most of the code you deal with is of the event handler variety. Yes, it’s possible to view the code for a form designer (like Form1.Designer.cs in .NETpad), but all you’ll find there are the contained control definitions. To view or change a property of the form or any of its controls, you have to use the Properties pane in Visual Studio.

This is the leap that Microsoft would make after Windows Forms, with the Avalon APIs in WinFX (which became Windows Presentation Foundation): the event handler code worked as before but the user interface was created using an XML offshoot called XAML that, like HTML, could/can be used to declare the structure of a user interface, in this case for a Windows app. And that is the code that Don Box and Chris Anderson wrote later, in 2003.

Which we’ll get to soon.