Chapter 3: Control Class Basics

This chapter explores the Control class, which provides basic functionality for the family of Windows controls. You will learn about fundamental topics like mouse and keyboard handling, focus, and control relations. Along the way, I''''ll also introduce some important pieces of the System.Drawing namespace that allow you to create structures that represent colors, fonts, rectangles, and points.

The Windows Forms Package

.NET provides two toolkits for user interface design: one for web applications, and one for Windows development. This chapter introduces the Windows Forms package, which allows you to create the traditional rich graphical interfaces found in everything from office productivity software to arcade games. The one detail that all these applications have in common is the fact that they are built out of windows-tiny pieces of screen real estate that can present information and receive user input.

It''''s easy to imagine that "Windows Forms" refers to a special part of the .NET class library, where fundamental classes like Form and Control are stored. This is true, but it isn''''t the whole story. More accurately, Windows Forms is the technology that allows the Common Language Runtime to interact with control objects and translate them into the low-level reality of the Windows operating system. In other words, you create objects that represent controls and windows, and the Common Language Runtime handles the details like routing messages, keeping track of window handles, and calling functions from the Windows API.

This idea isn''''t new. In the past, developers have used the MFC framework in C++, WFC in J++, and Visual Basic''''s own "Ruby" forms engine to insulate themselves from some of the low-level details of Windows programming. These frameworks all provide an object-oriented wrapper around the Windows API (which, on its own, is a disorganized collection holding hundreds of miscellaneous C routines). These frameworks were well intentioned, but they have all suffered from a few problems.

Lack of consistency. If you learn how to use MFC, you still won''''t know anything about creating Visual Basic user interfaces. Even though every framework ultimately interacts with the Windows API, they have dramatically different object models and philosophies.

Thin layer/thick layer problems. Frameworks tend to be either easy to use, or powerful, but not both. MFC is really only a couple of steps away from Windows messages and low-level grunt work. On the other hand, Visual Basic developers have the benefit of a simple framework, but face the lingering dread that they will need to delve into the raw Windows API for complex or unusual tasks that are beyond Visual Basic''''s bounds.

Subjugation to Windows API rules. The Windows API dictates certain harsh realities. For example, once you create a fixed-border window, you can''''t make its border resizable. These limitations make sense based on how the Windows API is organized, but they often lead to confusing inconsistencies in a framework''''s object model.

The result of these limitations is that there are essentially two types of frameworks: those that are complicated to use for simple tasks (like MFC), and those that are easy to use for simple tasks, but difficult or impossible to use for complex tasks (like VB). These object models provide a modern way to code user interfaces, but many programmers wonder why they should abstract the Windows API when its restrictions remain.

The .NET Solution

.NET addresses these problems by becoming more ambitious. The result is a user interface framework that uses some innovative sleight-of-hand to perform tasks that are difficult or impossible with the Windows API. Here are some examples- tasks that .NET can perform but the Windows API cannot:

Change fixed style properties like the selection type of a list box or the border type of a window.

Change a form''''s owner.

Move an MDI child window from one MDI parent window to another.

Transform an MDI child window into an MDI parent and vice versa.

Move controls from one window to another.

Clearly this list includes a couple of tricks that a self-respecting application will probably never need to use. Still, they illustrate an important fact: .NET doesn''''t just provide an easier object model to access the Windows API; it also provides capabilities that extend it. The result is a framework that works the way you would intuitively expect it to work based on its objects.

Note

The samples for this chapter include a project called ImpossibleAPI, which shows one of these "broken rules"-a child window that can jump between different MDI parents whenever the user clicks a button.

All of this raises an interesting question. How can a programming model built on the Windows API actually perform feats that the Windows API can''''t? Truthfully, there''''s nothing in the preceding list that couldn''''t be simulated with the Windows API with a fair bit of effort. For example, you could appear to change the border style of a window by destroying and recreating an identical window. To do so you would have to rigorously track and restore all the information from the previous window.

In fact, this is more or less what takes place in .NET. If you examine the control or window handle (the numeric value that identifies the window to the operating system), you''''ll see that it changes when you perform these unusual operations. This signifies that, on an operating system level, .NET actually provides you with a new window or control. The difference is that .NET handles this destruction and re-creation automatically. The illusion is so perfect that it''''s hardly an illusion at all (any more than the illusion that .NET web controls can maintain state, or that television shows continuous movement, rather than just a series of still images).

The cost of this functionality is a runtime that requires a fair bit of intelligence. However, .NET programs already need an intelligent runtime to provide modern features like improved code access security and managed memory. The Windows Forms are just another part of the ambitious and sprawling .NET framework.

Some programmers may still feel they need to resort to the Windows API. You can still use API calls in your .NET applications without too much trouble. However, I encourage you to abandon those habits and start dealing with the new .NET abstractions. Not only is it easier, it also provides a short path to some remarkable features.

Tip

One of the best pieces of advice for beginning programmers in traditional development was to master the Windows API. However, in .NET the story changes. In .NET, you''''ll get the most benefit by studying the low-level details of the .NET object libraries, not the API. Believe it or not, the operating system details will not be as important in the next generation of software development. Instead, you''''ll need to know the full range of properties, methods, and types that are at your fingertips to unlock the secrets of becoming a .NET guru.