Windows includes more than 20 built-in control types that programmers can use to conserve development time and give applications a look and feel that is consistent with other Windows applications. Push buttons and list boxes are examples of controls; so are tree views, toolbars, and status bars. Controls have been a staple of the Windows operating system since version 1, and the roster has grown over the years to include a rich and varied assortment of control types.

The System.Windows.Forms namespace provides managed wrappers around the built-in Windows controls and throws in a few controls of its own that have no direct analogue in the operating system. The following table lists them all. Each class exposes properties that vastly simplify control programming. Want to create a stylized button with a bitmapped background? No problem. Just wrap an image in a Bitmap object and assign it to the button’s BackgroundImage property. Another example involves control colors. Ever tried to customize the background color of an edit control? Other developers have, because I get e-mail asking about doing this all the time. In Windows Forms, it’s easy: you just write the color to the control’s BackColor property and then sit back and let the .NET Framework do the rest.

System.Windows.Forms Control Classes?




Push buttons


Check boxes


List boxes whose items include check boxes


Combo boxes


Controls that display tabular data


Edit controls hosted by DataGrid controls


Controls for selecting dates and times


Group boxes


Horizontal scroll bars


Label controls that display static text


Label controls that display hyperlinks


List boxes


List views (display flat lists of items in a variety of styles)


Month-calendar controls


Spinner buttons (up-down controls)


Controls that display images


Controls that display print previews


Progress bars


Controls that list the properties of other objects


Radio buttons


Rich-edit controls


Status bars


Tab controls


Edit controls






Track bars (slider controls)


Tree views (display hierarchical lists of items)


Vertical scroll bars

Creating a control and making it appear in a form is a three-step process:

  1. Instantiate the corresponding control class.

  2. Initialize the control by setting its property values.

  3. Add the control to the form by calling Add on the form’s Controls collection.

The following code creates a push button control and adds it to a form. The button measures 96 pixels by 24 pixels, and its upper left corner is positioned 16 pixels to the right of and 16 pixels below the form’s upper left corner. The text on the face of the button reads “Click Me”:

MyButton.Text?= "Click?Me";

Most controls fire events that apprise their owner of actions taken by the user. For example, button controls fire Click events when clicked. A form that wants to respond to clicks of MyButton can register an event handler this way:


EventHandler is a delegate defined in the System namespace. Recall that a delegate is a type-safe wrapper around a callback function and that delegates are especially useful for wiring events to event handlers. The event handler’s first parameter identifies the control that fired the event. The second parameter provides additional information about the event. As with events involving menu items, EventArgs contains no useful information. However, some controls pass other argument types to their event handlers. For example, tree view controls fire AfterExpand events after a branch of the tree expands. AfterExpand uses TreeViewEventHandler as its delegate. The second parameter passed to a TreeViewEventHandler is a TreeViewEventArgs that identifies the branch of the tree that was expanded.

How do you know what events a given control fires? You read the documentation. Look up ListBox, for example, and you’ll see that it defines an event named DoubleClick that’s fired whenever the user double-clicks an item in the list box. DoubleClick is prototyped this way:


From this statement, you know that handlers for DoubleClick events must be wrapped in EventHandler delegates. And because EventHandler is prototyped this way:


you know the signature for DoubleClick event handlers, too.

The ControlDemo Application

The application depicted in Figure 4-17 demonstrates the basics of Windows Forms control usage. Its one and only form contains four controls: a Label control, a TextBox control, a ListBox control, and a Button control. To put ControlDemo through its paces, start it up, type a path name (for example, C:\Winnt) into the TextBox control, and click the Show File Names button. A list of all the files in that directory will appear in the ListBox. Next double-click one of the file names to pop up a message box revealing when the file was created and when it was last modified.

ControlDemo’s source code appears in Figure 4-18. The application’s main form is an instance of MyForm. MyForm’s constructor instantiates the controls and stores references to them in private fields. Then it adds the controls to the form’s Controls collection so that they will physically appear in the form. Event handlers named OnShowFileNames and OnShowFileInfo respond to the push button’s Click events and the list box’s DoubleClick events. These handlers use static methods belonging to the System.IO namespace’s Directory and File classes to enumerate files and retrieve file information.

Note the statements that assign numeric values to the TextBox, ListBox, and Button controls’ TabIndex properties. TabIndex specifies the order in which the input focus cycles between the controls when the user presses the Tab key. The logic for moving the focus is provided by the framework; your only responsibility is to provide the order. The Label control isn’t assigned a tab index because it never receives the input focus.

Figure 4-17
ControlDemo showing file details.


















Figure 4-18
ControlDemo source code.

When the Windows Forms team in Redmond drew up the blueprints for their part of the .NET Framework, they decided to include a few bells and whistles, too. One of those bells and whistles is a feature called anchoring. Anchoring enables forms designers to create forms whose controls move and resize as the form is resized. Figure 4-19 shows how ControlDemo looks if its form is expanded. Even though the form is larger, the controls retain their original size. Figure 4-20 shows the same form with anchoring enabled. The controls now “flow” with the size of the form.

Anchoring is applied on a control-by-control basis. It’s enabled for a given control by initializing the Anchor property that the control inherits from Control. Anchor can be set to any combination of the following values to tell the control what to do when its container is resized:

Anchor Style



Maintain a constant distance between the left edge of the control and the left edge of the form


Maintain a constant distance between the right edge of the control and the right edge of the form


Maintain a constant distance between the top edge of the control and the top edge of the form


Maintain a constant distance between the bottom edge of the control and the bottom edge of the form


Don’t maintain a constant distance between the control and any edge of the form

If you want a control to move to the right when the container is widened, anchor the right edge of the control to the right edge of the form, like this:


If you want the control to widen rather than move when the form is widened, anchor both the left and right edges, like this:


By applying various combinations of anchor styles, you can configure a control to flow how you want it to when its container is resized.

To see anchoring in action first-hand, add the following statements to MyForm’s constructor in ControlDemo.cs:


These statements produce the result that you see in Figure 4-20. Specifically, they configure the TextBox control to expand horizontally as the form expands but to remain fixed with respect to the top of the form; they configure the ListBox control to stretch horizontally and vertically as the form expands; and they configure the Button control to remain fixed in size but move with the lower right corner of the form.

Figure 4-19
ControlDemo without anchoring.
Figure 4-20
ControlDemo with anchoring.