InitialDirectory

The InitialDirectory property lets you determine where in the user’s directory structure the dialog will display at first. You can set this to whatever you want, but it’s possible that the user’s directory structure will be unknown to you. The safest alternatives are in a directory your program has created (using the System.IO.Directory class) or in the program’s current working directory (denoted with a single period [.]). The default directory is wherever the program’s binary files are installed on the user’s machine. If you will be saving many files on the user’s machine, you might want to make a directory off the default directory and instruct dialog boxes to open in this directory.

The initial directory is just a starting place. The user is still free to navigate the entire drive system (and perhaps even the network) to save and load files.

Trick Initial directories are especially important if you are writing programs for beginning users. Beginners often ignore the entire directory structure and save their files wherever the dialog first points them. This can lead to disaster if your load dialog doesn’t point to the same initial directory as the save dialog.

Filter

The Filter property allows the programmer to determine which files will appear by default. The filter is useful because it limits the displayed files to those types of files the program is expecting. Typically, you either use a recognized standard file extension (such as .txt for plain text) or create your own extension for special−purpose file types. In either case, you should also add a filter to allow for all files, because often users still want to see every file in the directory. The file filter consists of a file description followed by the pipe symbol (|) and a pattern that returns the description. For example, this pattern

Text files (*.txt)|*.txt

places the value Text files (*.txt) in the Files of Type list box and displays all files that end with .txt in the directory listing. A filter can consist of multiple patterns. For example, both the DialogDemo file dialogs use the following pattern:

Text files (*.txt)|*.txt|All files (*.*)|*.*

Trap Be very careful with the patterns. If you put a space immediately after the pipe symbol, like this, Text files (*.txt)| *.txt the program will think that you are looking for files that begin with a space and end in .txt. Likewise, trailing spaces in a filter can cause the same kinds of problems. Test your filters carefully to ensure that they display exactly the types of files you’re expecting.

Responding to File Dialog Events

The file dialog objects generate events just like most other components. The FileOK event occurs when the user clicks the OK button after choosing a file. You can write code in the default event handler to deal with saving or loading the file. To retrieve the file name requested by the user, use the Filename property of the OpenFileDialog or SaveFileDialog control (whichever one you were using). Here’s the event handler code relating to the file dialogs in the Dialog Demo program:

private void mnuSaveAs_Click(object sender, System.EventArgs e) { fileSaver.ShowDialog();

}

254

private void fileSaver_FileOk(object sender, System.ComponentModel.CancelEventArgs e) {

StreamWriter sw = new StreamWriter(fileSaver.FileName); sw.Write(txtEdit.Text);

sw.Close();

}

private void mnuOpen_Click(object sender, System.EventArgs e) { fileGetter.ShowDialog();

}

private void fileGetter_FileOk(object sender, System.ComponentModel.CancelEventArgs e) {

StreamReader sr = new StreamReader(fileGetter.FileName); txtEdit.Text = sr.ReadToEnd();

sr.Close();

}

The mnuSaveAs_Click() method shows the fileSaver dialog box with the ShowDialog() method. The dialog then takes control of program flow until the user clicks OK or Cancel. If the user chooses Cancel, nothing further happens and the dialog closes down. If the user chooses OK, the fileSaver_FileOK() method leaps into action. It generates a stream writer based on the user’s choice of a file name. The user’s file name is stored in the FileName property of fileSaver, which is a SaveFileDialog. The method then writes the text to the stream writer and closes the stream.

The code for opening a file is very similar. A menu item click event—in this case, mnuOpen_Click()—shows the fileGetter, which is an OpenFileDialog. The fileGetter_FileOK() method triggers when the user clicks the OK button. This causes the creation of a StreamReader based on the user’s choice. The program reads the contents of the stream and copies the data to the text box. Finally, the method closes the StreamReader.

Using the Font Dialog Control

The FontDialog control works much like the file dialogs. It doesn’t change a font but asks the user to interactively choose a font, and that font is available as a property of the dialog for the programmer’s use. You add a font dialog to a form in the same way you add a file dialog. Drag it onto the form, and it moves to the off−screen area. Generally, it isn’t necessary to modify any of the font dialog’s properties, but you can preset the font to a font that will work well for your program. Although font dialogs also generate events, it makes more sense to work with the font information in the same code that calls the dialog. The code for the font menu item illustrates how this can be done:

private void mnuFont_Click(object sender, System.EventArgs e) { if (fontDialog1.ShowDialog() != DialogResult.Cancel){

txtEdit.Font = fontDialog1.Font;

} // end if

}// end mnuFont

The font dialog is displayed in the click event of the mnuFont object. However, this code takes advantage of the fact that the ShowDialog() method returns a value of type DialogResult. (As usual, I knew this only because I looked it up in the online help.) The program simultaneously displays the dialog and examines the result. If the result is not equal to DialogResult.Cancel, the program copies the Font property of the dialog to the Font property of the text box. The logic works like this: There are only two ways to get out of the dialog box—by clicking OK or Cancel. If the user clicks the Cancel button (indicated by a DialogResult.Cancel value), the program should simply move on. If the user chooses anything else (so that the result of the dialog is anything but DialogResult.Cancel),

255