Visual Inheritance

After all the settings and behavior details you've learned to pack into forms, you may decide to keep some of your hard work in a form-derived base class for easy reuse, and you can certainly do that. If you follow the convention that forms initialize their own properties and the properties of their child controls in a function called InitializeComponent, then the Designer provides direct support for your visual inheritance: the reuse of a form base class via inheritance.

The goal of visual inheritance is to allow a base class to capture common UI elements, which are then shared and augmented by derived classes. For example, imagine a BaseForm class that derives from Form and provides an icon, a menu strip, a status strip, an open file dialog, and a save file dialog, as shown in the Designer in Figure 2.40.

Figure 2.40. Base Class Used in Visual Inheritance

BaseForm can now serve as a base class for all forms that contain at least this functionality, such as the EditorForm shown in Figure 2.41. ^[24]

^[24] Make sure your project is compiled before you use the Designer on inherited forms.

Figure 2.41. EditorForm Derived from BaseForm

I created the EditorForm class by deriving from BaseForm, overriding the Text property, adding the TextBox control to the form, and overriding the various properties of the open and save file dialogs from the base class. Rather than do this work by hand, I used VS05. I right-clicked on the project in Solution Explorer, chose Add | Add New Item, and chose Inherited Form from the Add New Item dialog. Then, I set the form's name and chose BaseForm from the list of forms in the project displayed in the Inheritance Picker dialog, as shown in Figure 2.42.

Figure 2.42. The Inheritance Picker Dialog

The initial EditorForm looked just like BaseForm except for the little arrows over the menu and status strips and the open and save file dialogs (as shown in the bottom pane of Figure 2.41). This arrow indicates a control inherited from the base. After inheriting the new form class from the existing form class, I used the Toolbox to add the new controls, and I used the Properties window to change the form's Text property.

However, to configure the file dialogs, I first had to change their access modifiers. By default, the Designer adds all fields as private, and this means that they're accessible only from that classin our example, the BaseForm class. If you want to use the Designer to set a property on one of the controls in the base class from the deriving class, by default you can't until you change the access modifier in the field declaration in the base class:

private OpenFileDialog openFileDialog; private SaveFileDialog saveFileDialog;

To allow access by deriving classes, you change the private keyword to protected:

protected OpenFileDialog openFileDialog; protected SaveFileDialog saveFileDialog;

If you're really into Cooperesque visual design, you can change this keyword by using the Designer to select a control on BaseForm and changing the Modifiers property. ^[25]

^[25] Alan Cooper invented the drag-and-drop visual design mechanism for Visual Basic.

The purpose of this exercise in reuse is that when you need a new feature from the set of forms that derive from BaseForm or when you find a bug, you can make the changes to the base form, automatically benefiting the derived forms. For example, BaseForm could be updated to include generic serialization and deserialization that would automatically propagate to derived forms like EditorForm the next time BaseForm is compiled.

As nifty as visual inheritance is, it's not without limitations. For example, although you can completely replace the context menu of a base form in a derived form, you can't change the configurations of inherited tool strip controls, layout-panel controls, and DataGridView because they are all locked. Also, multilevel visual inheritance can lead to brittleness, perhaps forcing you to write more code in your derivations than you had hoped to save by using visual inheritance.

One good rule of thumb is to add only inheritable functionality that's required by all direct and indirect derivations. Additionally, if you provide an area for derivations to insert their own controlsas BaseForm allowed EditorForm to do with a text boxthe functionality you add should support any possible combination of added controls.

With judicious use, visual inheritance is definitely worth your consideration as a template mechanism to avoid duplicating controls and code.