///<summary>

///Required method for Designer support - do not modify

///the contents of this method with the code editor.

///</summary>

private void InitializeComponent()

{

components = new System.ComponentModel.Container();

. . .

}

#endregion

. . .

}

}

Take a look at the properties for the PhotoEditDlg object. The form has inherited all of the settings from our BaseEditDlg form to make it into a dialog box. The buttons and panel from the base class appear on the form as well, and you can examine the properties for the individual buttons. Note in particular that the OK, Reset, and Cancel buttons are private and cannot be modified, while the protected Panel can.

We will leave the topic of inherited forms for now and move on to specific controls for our PhotoEditDlg form. Before we do, it is worth realizing how powerful this feature really is. For example, a standard form for a database table could be created. Applications that use this table can customize the form for their specific needs, or libraries that extend the existing database can build a new form based on the original. In many cases, changes to the original database can be encoded in the base class in such a way that no changes are required in the inherited forms.

When you need a set of forms in your application based on a common concept or theme, consider creating a base form from which other forms can be derived.

9.2LABELS AND TEXT BOXES

In our MyPhotos application, we have already used the Label and TextBox classes while creating dialog boxes in chapter 8. Here we will look at these classes in a bit more detail as we place them on our PhotoEditDlg form.

To do this, we need to come up with some reasonable properties in our

graph class that will facilitate the creation of these and other controls. The following features will serve our purposes rather well:

•Caption—a caption for the photo. We created this property in chapter 8.

•Date—the date the photograph was taken. We will present this as a string on our form here, and convert our dialog to use the DateTimePicker control in chapter 11.

•Photographer—the person who took the photo. For now, we will treat this setting as a string. Later in the book this setting will be taken from a list of possible photographers.

•Notes—random notes or other comments about the photograph.

A dialog to support these new settings is shown in figure 9.2. This dialog will be constructed and discussed over the next few sections. In this section we will create the infrastructure required in the Photograph class to support these new settings, add the required controls to the dialog, and invoke the dialog from the main form of our MyPhotos class. We also look at some of the settings and events provided by the TextBox class for modifying the behavior or appearance of the control.

We will start with the changes required in our Photograph class.

Figure 9.2

Our Photo Properties dialog adds Label and Textbox controls to our inherited form.

9.2.1EXPANDING THE PHOTOGRAPH CLASS

In order to support the date, photograph, and notes settings in our photos, we need to make a few changes. This section adds these features to our Photograph object, as well as the ability to read and write photographs, and update the Save and Open methods in our PhotoAlbum class.

We begin with some variables to hold these values and properties to provide external access.

Set the version number of the MyPhotoAlbum library to 9.2.

ADD NEW MEMBERS TO THE PHOTOGRAPH CLASS

ADD NEW MEMBERS TO THE PHOTOGRAPH CLASS (continued)

This code is similar to member fields and properties we have seen before, except for the DateTime structure. This structure represents an instant in time measured in 100 nanosecond units since 12:00:00 AM on January 1, 0001, with a maximum value of 11:59:59 PM on December 31, 9999. Each nanosecond unit of time is called a tick. Members of this structure allow you to add, subtract, format, and otherwise manipulate date and time values. A related TimeSpan structure represents an interval of time. You can look up these structures in the .NET Framework documentation for more information on these types.

With our fields and properties defined, we next need to store and retrieve these values in the Save and Open methods of our PhotoAlbum class. Since the Photograph class is becoming a bit more complex, we will create Read and Write methods in this class to encapsulate the logic required. The Write method will store a photo into an open StreamWriter object, while various Read methods will accept an open

StreamReader and return a Photograph object.

In our PhotoAlbum class, we will use these new methods to save and load a new version of our album file. It will be version 92, to match the current section of the book.

Let's continue our previous steps and create Read and Write methods in our

Photograph class.

ADD READ AND WRITE METHODS TO THE PHOTOGRAPH CLASS

ADD READ AND WRITE METHODS TO THE PHOTOGRAPH CLASS (continued)

Before we update the Save and Open methods in the PhotoAlbum class, a short discussion of our sudden use of the delegate keyword is in order.

We briefly mentioned in chapter 1 that a delegate acts much like a function pointer in C++. It identifies the signature for a method without actually defining a method. The advantage of C# delegates is that they are type safe. It is impossible to assign a nonconforming method to a delegate.

In our code, we create a delegate called ReadDelegate. This delegate encapsulates methods that accept a single StreamReader parameter and return a Photograph object. It just so happens that this matches the signature of the three read methods we created in the prior steps. This delegate can be used to great advantage when opening an album. Let’s see how this looks.