Windows Forms Applications

If you’ve ever programmed in Microsoft Visual Basic, the idea behind Windows Forms will be familiar to you. In fact, for the .NET Framework, Microsoft has taken the Visual Basic GUI programming model, complete with forms, controls, and properties, and generalized it so that it can be used from any .NET language.

A Windows Forms application consists of one or more windows called forms. These might be top-level windows, child windows, or dialog boxes, and an application might support many different forms. You place controls—such as buttons and list boxes—onto a form to build the GUI for your program. A simple form is shown in the following figure.

This form is a top-level window that is resizable and has a title bar; it also has Minimize, Maximize, and Close buttons on the right and a system menu button on the left. It contains a selection of common controls, including a button, radio buttons, a group box, and a combo box.

Note

You can also draw on forms using the classes in the System::Drawing namespace; we’ll cover drawing on forms in Chapter 18.

Windows Forms and Designers

Although you can write code to generate forms, you will normally use designers to create the user interface. Microsoft Visual Studio .NET supports graphical GUI construction using designers, which put a form on the screen and let you drag components from a Toolbox and drop them onto the form. A Properties editor lets you set the properties of forms and controls—such as color and text—and makes it easy to add event handlers. This way of developing forms will be familiar to anyone who has used Visual Basic in the past.

Forms are always constructed at run time by executing code, and designers simply take what you do on the screen and generate code underneath, which will create the user interface for you at run time. If you open a Visual Basic or C# project and look at the source code, you’ll see a section labeled “Windows Form Designer generated code,” which contains that code.

There was no designer for Microsoft Visual C++ included in the first release of Visual Studio .NET, so you had to create and populate forms yourself by writing code. Version 7.1 includes a C++ designer, so you can develop GUI applications in the same way that you would in Visual C# or Visual Basic .NET.

Windows Forms vs. MFC

Since its earliest days, Visual C++ has shipped with a library called MFC (Microsoft Foundation Classes). This library is used for writing C++ applications for Microsoft Windows, and it encapsulates mostly that part of the Windows API that deals with GUI programming, along with some other areas such as databases and networking.

MFC has become a standard for writing Windows applications in Visual C++. The latest version ships with Visual Studio .NET, and there’s a lot of MFC code still around. It has nothing to do with .NET, however, and you probably won’t want to use it for new Windows development in C++.

However, you still might need to use MFC when

• You have an MFC application, and you aren’t updating it (or can’t update it) to use Windows Forms.

• You’ve got to use some existing MFC components.

• You really like the MFC Document-View architecture, which isn’t supported in the .NET Framework.

In the vast majority of cases, though, you’ll want to use the .NET Framework. The object-oriented coverage of the Windows API is more complete, and it’s better object-oriented code. Plus, mixed-language programming is easy with .NET.

A Word About ATL

While on the subject of C++ libraries for Windows programming, I’ll also mention the other major Microsoft offering, the Active Template Library (ATL). ATL is a C++ library for writing the smallest, fastest COM objects possible. As such, it’s a very specialized library, and few people will need to use it now that the .NET Framework has made COM less of a mainstream technology.

Note

The .NET Framework makes it less necessary for developers to know about and use COM because it provides technologies that make some of the traditional uses of COM (for example, general components and Microsoft ActiveX controls) less necessary. So, COM has been pushed more into the background as a specialized, mainly server-side technology. If you want to know more about using COM with .NET, take a look at COM Programming with Microsoft .NET by Julian Templeman and John Paul Mueller (Microsoft Press, 2003).