Making Forms Useful

Any form identified as your project's startup object appears automatically when the program begins. All other forms need to be displayed manually, using either the Show or ShowDialog methods of that form. For instance, if you have a form called Form2, you can display it using its Show method:

Form2.Show() 

The Show method displays a modeless form. Modeless forms can be accessed independently from all other forms in the running application. All modeless forms can be activated at any time just by clicking on them; the form you click on will come to the front of the others and receive the input focus. A program might have one, two, or dozens of modeless forms open at once, and the user can move between them freely.

Modal forms take control of all input in the application for as long as they appear on-screen. Modal forms are commonly called "dialogs"; the user must complete a modal form and close it before any other open forms in the application can be accessed. The message box window that appears when you use the MsgBox function is a common modal dialog window. The ShowDialog method displays forms modally, and lets you return a value from that form. The values returned are the members of the System.Windows.Forms.DialogResult enumeration.

If you think of forms as works of literature by Alexandre Dumas, then modeless forms would be a lot like The Three Musketeers: All for one and one for all. They work with each other in support of the entire application. Modal forms are akin to The Count of Monte Cristo. Yes, there are other forms/characters in the application/story, but they are nothing when the Count is in view.

To display the Countthat is, a modal formuse the form's ShowDialog method, and optionally capture its return value.

Dim theResult As DialogResult theResult = Form2.ShowDialog() 

Modal dialogs are useful for editing some record that requires a click on the OK button when changes are complete. Let's say you were writing an application that displayed a list of books by Alexandre Dumas. It might include two forms: (1) a "parent" form that displays the list of books; and (2) a "child" form that lets you type the name of a single book. Wouldn't it be great if you could return the name of the book (or, perhaps, an ID number of a record for the book as stored in a database) instead of a DialogResult value?

If the ShowDialog method, a public method of the underlying Form class, can return a result code, perhaps we can add another public method to a form that will return a result code that has actual meaning? Indeed we can. Consider the child form (named BookEntry) with a data entry field (BookTitle), and OK (ActOK) and Cancel (ActCancel) buttons, as shown in Figure 7-10.

Figure 7-10. Book title entry form

This simple form just returns whatever is typed in the field when the user clicks OK (first rejecting blank values), or returns a blank string on Cancel.

Public Class BookEntry    Public Function EditTitle() As String       ' ----- Show the form, and return what the user enters.       If (Me.ShowDialog() = DialogResult.OK) Then          Return BookTitle.Text.Trim       Else          Return ""       End If    End Function    Private Sub ActCancel_Click(ByVal sender As System.Object, _          ByVal e As System.EventArgs) Handles ActCancel.Click       ' ----- Return a blank title for "Cancel."       Me.DialogResult = DialogResult.Cancel       ' ----- Continue with EditTitle()    End Sub    Private Sub ActOK_Click(ByVal sender As System.Object, _          ByVal e As System.EventArgs) Handles ActOK.Click       ' ----- Only accept valid titles.       If (Len(BookTitle.Text.Trim) = 0) Then          MsgBox("Please supply a valid title.")       Else          Me.DialogResult = DialogResult.OK          ' ----- Continue with EditTitle()       End If    End Sub End Class 

To use this form, the parent calls the EditTitle method, which returns the book title entered by the user.

Dim newTitle As String = BookEntry.EditTitle() 

The EditTitle routine shows the form modally with the ShowDialog method, and just sits there until the user closes the form. Closing the form is done through the OK or Cancel button events; setting the form's DialogResult property has the side effect of closing the form. Great!

Once the form closes, execution returns to EditTitle, which does a quick status check before returning the final value. And there we have it: a new public interface for a form's most important return value. We'll use this method a lot in the Library Project application.