Chapter 5: Windows Forms

Below there! Oiler! What’s your wark? Ye find her runnin’ hard?
Ye needn’t swill the cap wi’ oil—this isn’t the Cunard.
Ye thought? Ye are not paid to think. Go, sweat that off again!
Tck! Tck! It’s deeficult to sweer nor tak’ The Name in vain!

—Rudyard Kipling, writing on the difficulty of training system
administrators and the consequent need to supply them with foolproof tools,
“McAndrew’s Hymn,” 1894.

Problem Background

This book has until now primarily discussed using Microsoft .NET for writing server-side code, and .NET is very good for that. However, what operating system is running on all the desktop PCs at your business, the good one in your home that you use for take-home work, and the old one you let the kids hack with (or the other way around)? The laptop of the guy next to you on the airplane? Except for a few religious Macintosh adherents and some geeky Linux hobbyists, it’s Microsoft Windows. It seems to me that developers often forget that Windows runs on many more client machines than it ever will on servers, probably by a factor of 100 or more. Did those users choose Windows for its transaction throughput or scalability to server farms? No. They chose it because it has a good user interface and lots of available desktop software. It’s the largest software market in the world and will be for the foreseeable future. We’ll be writing different types of desktop applications from what we wrote a decade ago. Spreadsheets and word processors have been pretty much beaten into the ground, but we’ll still be writing for the Windows desktop. For example, we’ll be writing more rich front ends for Internet applications, such as the Kazaa music search program that I showed you in Chapter 4.

The Windows desktop software market is the largest in the world and will remain so for the foreseeable future.

Some of the architectural problems that desktop developers face are different from those of server developers. For example, a desktop developer deals with a single human being who reacts slowly compared to a computer, so the developer generally has plenty of CPU cycles available and doesn’t have to worry about scalability the way a server developer does. On the other hand, many of the problems that desktop developers face are the same. For example, both types of developers care about reusing code that other developers wrote. They might reuse different types of code—say, code for database access vs. graphical animation—but they both face the economic necessity of leveraging the efforts of other developers. They both care about versioning. They both care about abstracting away distinctions between different language implementations. They both care about interoperating with COM. Desktop developers have largely ignored security until now, considering it only a server-side problem, but now that a lot of code is delivered over the Web, desktop developers face the twin problems of authentication and authorization that have long deviled their server-side colleagues. Welcome to the real world. Developers writing desktop apps need prefabricated solutions to these problems just as server developers do.

Developers of desktop software face many of the same problems as developers of server software.

In addition to the problems they share with server developers, desktop developers have their own set of problems. I remember writing Windows desktop apps in C about a decade ago. I spent most of my time writing code for user interface features that all Windows applications needed. Prefabricated status bars and toolbars didn’t exist then, so I had to write code for my own and so did every other developer who wanted to implement these features in an application. I had to write my own command handlers for receiving messages from controls. I still have nightmares about the time I foolishly promised a client that I’d add a print preview feature to his program for a fixed fee. (You live and learn, or you don’t live long, and you definitely don’t prosper.) For every programmer to write her own implementation of all these common user interface items makes no sense, either economically (all that duplicated, triplicated, octuplicated programmer effort) or ergonomically (every toolbar works differently, which drives users barking mad). We need prefabricated solutions for these common UI design problems.

Most GUI applications require a common set of features, opening the way for prefabricated functionality.

Seizing the opportunity to provide standards that developers could reuse, different development environments provided different approaches to prefabricated user interfaces. Visual Basic offered a programming model based on events and forms that became quite popular for its ease of use. Visual C++ offered the Microsoft Foundation Classes (MFC), which used C++ inheritance to provide prefabricated functionality, such as the print preview feature I banged my head against so long ago. The code-based design in Visual C++ was harder to use than Visual Basic’s forms-based model, but its underlying language was much more powerful. Programmers had to choose between a powerful language and rapid GUI design features. I’d often choose Visual Basic to write a front end because I liked its form editor and the ease of connecting with controls, but the wimpy language, with its arcane syntax for COM objects, its idiotic error handling, and the difficulty of calling API functions to do common tasks such as manipulate the registry would send me through the ceiling. Or I’d choose Visual C++ for its powerful language, in which case its lower-level of abstraction—for example, the difficulty of handling and firing connection point events—would send me through the ceiling.

A desktop programmer often chose a particular programming language because of its prefabricated user interface support rather than its fit to the problem domain.

Like everybody else in the world, desktop developers want everything, all at once, and we don’t want to trade anything else away to get it. We want prefabricated solutions to the problems we share with server developers. We want rapid GUI development, but we want it to work with a powerful programming language, ideally the powerful programming language of our choice. For consistency’s sake, we want it all to use the same programming model. And we want it to cost relatively little. As long as we’re writing to Santa Claus, it couldn’t hurt to at least ask for a pony.

As usual, we want everything but our business logic done for us (and I wouldn’t mind if someone did that, too).