Control Appearance and Behavior

function OpenWin(url, w, h) { if(!w) w = 400; if(!h) h = 300; window.open(url, "_new", "width=" + w + ",height=" + h + ",menubar=no,toobar=no,scrollbars=yes", true); }

During development of a custom control, the main goal is to produce a control that is concise in its intended use. After all, if the control's use eludes the end user, the control's development is really pointless. The user might as well have chosen a better-known control or one of the common controls. Make sure that your users understand the intended use of your control.

When you are developing a control that is useful, it is also important to know your targeted audience. When you are developing custom controls, there are two target audiences. The first is the developer who will use your control when building an application, and the second is the end user of the application. Although the developer may understand the use of the control, you must ensure that the end user of the application will also understand how to use the control. Custom control developers sometimes forget about end users and focus solely on the developers who will be purchasing the controls and using them to build applications. However, when end users complain that the application is difficult to use, don't expect the developers to come back and purchase any more custom controls from you.

Custom control development consists of four major areas: properties, events, runtime, and design-time. Each of these is discussed in the following sections and throughout this book.

Properties

Properties are the main mechanism for controlling the appearance of a control. Aspects from color and size to text and images are defined using properties.

Using properties to define characteristics of a control is part of the Rapid Application Development, or RAD, style of application development. Coupled with RAD is the capability to create small reusable modules of code such as custom controls. This capability spawned a huge success for Microsoft Visual Basic.

The basic premise of properties was to replace the method call style invocation with a dot style notation. Under the covers, the dot style notation is actually a method call, but to the developer the dot style notation provides a layer of abstraction. Listing 1.1 shows a method call and a property reference or dot notation that sets a person's name.

Listing 1.1 Method Call Versus Dot Notation Properties

 1: //Method Calls to set person's name 2: Person me; 3: me.SetFirstName( "Richard" ); 4: me.SetLastName( "Weeks" ); 5: 6: //Property or Dot Notation 7: Person grandfather; 8: grandfather.FirstName = "Howard"; 9: grandfather.LastName = "Henry"; 

The code snippet in Listing 1.1 shows the stylistic difference between using method calls, lines 3 and 4, and using the dot notation of properties, lines 8 and 9. The result is the same in both cases. The first and last name of the Person object is set. The debate over which is better or preferred is often discussed; however, know that properties and the dot notation are a requirement for developing well-behaved and well-received custom controls.

Events

Events provide a basic mechanism for notification between various components. When the left mouse button is clicked on a control, the control in turn fires off a click event to be handled by the application. These events allow for an application to respond to user- or system-generated actions. Controls fire events to notify the application that some action has taken place and the application should in turn do something. That "something" is, of course, application specific.

Runtime

The runtime appearance and behavior of a control are what the end user of an application experiences. Thus, when an application is being used, the controls within the application have a defined appearance and a set of behaviors that are controlled by the application itself. Certain aspects of a control can be modified during runtime, such as the color and font used. The properties of a control can be modified in the application code, and may even be exposed to the user of the application. End users of the application do not typically modify the appearance of a control; rather, modifications to the control are performed by application code.

For the most part, however, when an application is running, the control cannot be altered in terms of its behavior. The behavior of the control that is, the logic handling the control's events is defined during the design and development of the application.

Design-Time

With the RAD style of development, application developers work with a design-time tool such as Visual Studio to create applications. During the design of an application, the developer will assign values to various properties of a control and write custom code to handle any events fired by the control. The design-time cycle of a project is interactive between the developer and the controls being used within the application. To a custom control developer, it is of paramount importance to create a control with solid design-time support. Figure 1.2 shows the Outlook-style control. You are shown an Outlook-style control as it is developed at design-time in Chapters 7, 8 and 9.

Figure 1.2. Design-time development using the Outlook-style control.

It is during the design-time development of an application that the developers (one of your target audiences) are addressed. If the custom control is hard for the developer to use to build applications, chances are the developer will give up and purchase a different custom control to get the job done.

Pleasing developers is a difficult task. It is important to get feedback from the developers using your custom control and to incorporate their comments into the control's design and usability. It is also helpful to look at the current set of controls and their design-time support. Perfecting the design-time support of a control takes time and several iterations of the controls designer. Designers are covered in Chapter 3, "Designer Basics."