Just as you can design custom classes, you can use Visual Studio to design custom controls. The process is very similar, in the sense that custom controls have properties, methods, and events, which are implemented with code that’s identical to the code you’d use to implement these members with classes. The difference is that controls have a visual interface and interact with the user. In short, you must provide the code to draw the control’s surface, as well as react to selected user actions from within the control’s code.
Before I get to the details of how to build custom controls, I want to show you how they relate to other types of projects. I’ll discuss briefly the similarities and differences among Windows controls, classes, and Windows projects. This information will help you get the big picture and put together the pieces of the following sections.
A standard application consists of a main form and several (optional) auxiliary forms. The auxiliary forms support the main form because they usually accept user data that are processed by the code in the main form. You can think of a custom control as a form and think of its Properties window as the auxiliary form.
An application interacts with the user through its interface. The developer decides how the forms interact with the user, and the user has to follow these rules. Something similar happens with custom controls. The custom control provides a well-defined interface, which consists of properties and methods. This is the only way to manipulate the control. Just as users of your applications don’t have access to the source code and can’t modify the application, developers can’t see the control’s source code and must access it through the interface exposed by the control. After an instance of the custom control is placed on the form, you can manipulate it through its properties and methods, and you never get to see its code.
In preceding chapters, you learned how to implement interfaces consisting of properties and methods and how to raise events from within a class. This is how you build the interface of a custom Windows control: You implement properties with Property procedures, and you implement methods as Public procedures. Although a class can provide a few properties and any number of methods, a control must provide a large number of properties. A developer who places your custom control on a form expects to see the properties that are common to all the controls (properties to set the control’s dimensions, its color, the text font, the Index and Tag properties, and so on). Fortunately, many of the standard properties are exposed automatically. The developer also expects to be able to program all the common events, such as the mouse and keyboard events, as well as some events that are unique to the custom control.
The design of a Windows control is similar to the design of a form. You place controls on a form-like object, called UserControl, which is the control’s surface. It provides nearly all the methods of a standard form, and you can adjust its appearance with the drawing methods. In other words, you can use familiar programming techniques to draw a custom control or you can use existing controls to build a custom control.
The forms of an application are the windows you see on the desktop when the application is executed.When you design the application, you can rearrange the controls on a form and program how they react to user actions. Windows controls are also windows, only they can’t exist on their own and can’t be placed on the desktop. They must be placed on forms.
The major difference between forms and custom controls is that custom controls can exist in two runtime modes. When the developer places a control on a form, the control is actually running. When you set a control’s property through the Properties window, something happens to the control — its appearance changes or the control rejects the changes. It means that the code of the custom control is executing, even though the project on which the control is used is in design mode.When the developer starts the application, the custom control is already running. However, the control must be able to distinguish when the project is in design or execution mode and behave accordingly. Here’s the first property of the UserControl object you will be using quite frequently in your code: the DesignMode property. When the control is positioned on a form and used in the Designer, the DesignMode property is True.When the developer executes the project that contains the control, the DesignMode property is False.
This dual runtime mode of a Windows control is something you’ll have to get used to. When you design custom controls, you must also switch between the roles of Windows control developer (the programmer who designs the control) and application developer (the programmer who uses the control).
In summary, a custom control is an application with a visible user interface as well as an invisible programming interface. The visible interface is what the developer sees when an instance of the control is placed on the form, which is also what the user sees on the form when the project is placed in runtime mode. The developer using the control can manipulate it through its properties and methods. The control’s properties can be set at both design time and runtime, whereas methods must be called from within the code of the application that uses the control. The properties and methods constitute the control’s invisible interface (or the developer interface, as opposed to the user interface). You, the control developer, will develop the visible user interface on a UserControl object, which is almost identical to the Form object; it’s like designing a standard application. As far as the control’s invisible interface goes, it’s like designing a class.
