.NET Windows Forms in a Nutshell
| Windows provides several kinds of widely used controls, such as buttons and text boxes, which act as the fundamental building blocks in most user interfaces. All these standard control types have .NET equivalents. This section shows which controls are available and what their Win32 equivalents are. It also describes some of the issues common to all the standard controls. More detailed technical descriptions of each control can be found in the reference section. 2.3.1 Available Controls
Table 2-1 shows the list of available controls and the nearest equivalent window class in Win32. (Some Win32 classes, such as Button , have several different modes, each of which is represented by a different class in Windows Forms. In this case, a Win32 window style is also specified to indicate which particular flavor of this class the relevant .NET type represents.) Table 2-1. .NET controls and their equivalent Win32 control classes
Note that some controls don't have an equivalent Win32 window classthe Windows Forms class library adds some new features. There are also some Win32 controls that appear to be absent, but in most cases, this is because their roles can be filled by one of the other controls. For example, Windows Forms does not provide a direct replacement for the Animation control, but this is because the PictureBox control supports animated bitmaps. There is also no ToolTip control, but ToolTips are dealt with through a different mechanism, called an extender property . The Win32 DragList , Header , and Pager control types don't have any equivalent in Windows Forms. 2.3.2 Using the Built-in Controls
Not all the features supported by the Control class make sense for certain controls. For example, the GroupBox control does not respond to mouse eventsits only purpose is to provide a visual grouping for controls. Fortunately, if you use Visual Studio .NET it will only present the features supported by the controls you use. (Chapter 5 explains how to determine which features are enabled for any custom controls you write, and Chapter 8 shows how to control the way in which Visual Studio. NET presents these features.) Some controls ( group boxes, labels, and all three button types) support a property called FlatStyle . This property modifies the way controls are drawn. By default, it is set to Flat.Standard , which means the control is drawn by the Windows Forms class library and not by the underlying OS. While this means that extra nonstandard functionality is available (e.g., the ability to set background colors or images), it has the disadvantage that your application will not be able to take advantage of themed controls. So in Windows XP, buttons will come out looking like normal Windows 2000 buttons regardless of what theme the user may be running with. If you would like to have themed controls (and don't mind losing support for background color and bitmaps), you must set the FlatStyle property to FlatStyle.System . [2] Although this means that Windows Forms will now let the operating system draw the controls, this in itself is not enough to get themed controlsas with any theme-aware application, you must also supply a manifest file. (Application manifests in .NET are used in exactly the same way as they are for non-.NET programs. They also have nothing to do with .NET assembly manifests. Consult the Win32 SDK documentation for details on how to create and use such manifests .) [2] To complicate matters further, some controls, e.g., TextBox , use system drawing in any case. These controls don't support background bitmaps and colors, so they never need to draw themselves . |