displays descriptive text about the photo, and automatically scrolls if the text becomes too long. The following steps add this control to our dialog:

ADD A MULTILINE TEXTBOX TO THE PHOTOEDITDLG FORM

Our form is now ready, except for the internal logic to process the user’s changes. Since our dialog is intended to edit a Photograph object within a PhotoAlbum

collection, we need a reference to the associated PhotoAlbum object within the dialog. We should also implement the methods necessary to handle the OK and Reset buttons, namely the ResetSettings and SaveSettings methods provided by the

BaseEditDlg class.

The following steps detail these changes:

INTERACTING WITH THE PHOTOALBUM OBJECT

Our dialog is complete, at least for now. Applications can use it to display and modify information about a photograph. The one exception is the date a photograph was taken. While it is certainly possible to convert a string provided by the user into a DateTime structure, this is not really the best way to specify a date on a form. Instead, the DateTimePicker control is provided especially for this purpose. We will look at this control in chapter 11, and simply ignore the value of txtDate for now.

The next step is to use this new dialog in our main application. This is the topic of the next section.

9.2.4ADDING PHOTOEDITDLG TO OUR MAIN FORM

Now that our new dialog is ready, we need to display it in our MyPhotos application.

This section integrates the dialog into our application, much like we integrated the CaptionDlg form in chapter 8.

The CaptionDlg form does present a slight problem, in that it already allows the caption to be edited, just like our new PhotoEditDlg form. We could keep this dialog around and provide two ways to edit a photograph’s caption. This might be a little confusing to users, so we will instead remove CaptionDlg from our application.

The step to remove this dialog follows. We will integrate the PhotoEditDlg dialog into our application in a moment.

Set the version number of the MyPhotos application to 9.2.

With the caption dialog gone, our way is clear to display the PhotoEditDlg form from our main window. We will reuse the menuCaption menu for this purpose, renamed and revamped by the following steps:

DISPLAY THE PHOTOEDITDLG FORM FROM THE MAIN WINDOW

Since the dialog itself handles the initialization and storage of any changes made by the user, and the using statement disposes of the dialog when we are finished, there is not much work required by our handler. When the user clicks OK, we mark that the album has changed and update the status bar with any new caption entered by the user.

So let’s see if your code actually works. Compile and run the application and open a previously saved album file. Display the Photo Properties dialog. Note in particular the following features:

•The differences between the read-only and editable text boxes.

•Label text cannot be highlighted, while text within text boxes can, even when read-only.

•Use the access key for a label and notice how the following text box receives focus.

•Press the Enter key while editing a single-line text box. The dialog behaves as if you had clicked the OK button.

•Press the Enter key while editing within the Notes text box. Since we set the AcceptsReturn property to true, this adds a new line within the Notes box and does not deactivate the window.

•Right-click on any text box. The default context menu will appear. This context menu contains various commands for editing text, and is shown in figure 9.3. The items in this menu correspond to methods in the TextBoxBase class, as shown in .NET Table 9.2.

While our form is working just fine, there are some features missing that might make our dialog a little more friendly. These are the subject of the next section.

Figure 9.3

The standard context menu for TextBox controls, shown here for the Date Taken text box, disables commands that are not currently available.

9.2.5USING TEXTBOX CONTROLS

So let’s add some interesting features to our text boxes. Most of the events for TextBox controls are inherited from the Control and TextBoxBase classes. Members

specific to the TextBox class appear in .NET Table 9.3. Here we will look more closely at the KeyPress event and the TextChanged event.

The keyboard events inherited from the Control class are especially interesting, and consist of the KeyDown, KeyPress, and KeyUp events. These events are inherited from the Control class, and occur when a key on the keyboard is pushed down and released while the control has focus. The KeyDown event occurs when the key is first pressed. The KeyPress event activates while the key is held down and repeats while the key remains held down. The KeyUp event occurs when the key is released. These events can be used to fine-tune your interfaces as the user types on the keyboard.

.NET Table 9.3 TextBox class

The TextBox class represents a TextBoxBase control that displays a single font. This control is part of the System.Windows.Forms namespace, and inherits from the TextBoxBase control. Through its parent class, text boxes can support single or multiple lines, and interact with the clipboard to cut, copy, or paste text.

We will look at the keyboard events in more detail in chapter 12, but let’s do a quick example here. Suppose we wanted the Caption property to only contain letters or numbers. No punctuation characters and no symbols. The KeyPress event receives keyboard characters as they are typed, and allows the event handler to handle or ignore them. The KeyPressEventArgs class is used with this event, and provides a KeyChar property to get the character pressed, and a Handled property to get or set whether the character has been handled. If Handled is set to true, then the control will not receive the character.

The obvious, albeit incorrect, way to implement such a handler would be as follows:

private void txtCaption_KeyPress(object sender, KeyPressEventArgs e)

{