Working with the windows 7 common file dialogs (part 3) - Defining a File Save Dialog

4. Defining a File Save Dialog

The new File Save dialog is every bit as flexible and programmable as the File Open dialog. Depending on what your application requires, you may create more or fewer additions to the File Save dialog. Getting users to put files in the right place and not overwrite existing files with completely different versions are two major considerations when creating the File Save dialog box. Listing 3 shows the code used for this example. You'll find that the File Save dialog, like the File Open dialog, offers significantly more options than shown here.

Example 3. Defining a File Save dialog box

private void btnSave_Click(object sender, EventArgs e) { // Define the dialog box. CommonSaveFileDialog dlgSave = new CommonSaveFileDialog("File Save"); // Add some alternative places to find data. ShellContainer Place = KnownFolders.DocumentsLibrary as ShellContainer; dlgSave.AddPlace(Place, FileDialogAddPlaceLocation.Top); dlgSave.AddPlace(@"C:\Test", FileDialogAddPlaceLocation.Top); // Add selection filters. dlgSave.Filters.Add(new CommonFileDialogFilter("Text File", ".txt")); dlgSave.Filters.Add(new CommonFileDialogFilter("HTML File", ".htm,.html")); dlgSave.Filters.Add(new CommonFileDialogFilter("Document File", ".doc")); // Show the dialog box. CommonFileDialogResult Result = dlgSave.ShowDialog(this.Handle); // Check the selection results. if (Result == CommonFileDialogResult.OK) // Display the selected file. MessageBox.Show("The user saved the file as: " + dlgSave.FileName); else // The user clicked Cancel. MessageBox.Show("User clicked Cancel"); }

The code begins by creating the File Save dialog, dlgSave, as a CommonSaveFileDialog object. As with the File Open dialog, you supply a dialog box name as part of the CommonSaveFileDialog() constructor.

You should provide symmetry between the File Open dialog and File Save dialog locations. If you add special locations for the File Open dialog, you should provide the same locations for the File Save dialog, unless your company has a policy about precisely where the user saves files locally or on the network that would conflict with a symmetrical approach. Using a symmetrical approach tends to reduce user confusion, which reduces training and support costs.

Figure 4. The File Save dialog box has many of the same features as the File Open dialog box.

The same consideration applies for filters. The example code adds precisely the same filters for both the File Open and File Save dialog boxes, using the Filters.Add().HTM and .HTML files, then the other method. Make sure that you address any specifics as part of creating the filter sets. If one filter set allows both filter set should allow both of them as well.

This example ends like the File Open dialog box by displaying the dialog box and then showing the result. As with the File Open example, the filename the user selects for saving the file appears as part of the Filename property. However, unlike the File Open example, the user can't ever save multiple files using a single save process. The user will always save one file at a time. Figure 4 shows how the File Save dialog box appears on-screen.

Figure 5. The File Save dialog box comes with built-in functionality to prevent file overwrites.

The File Save dialog box includes a built-in feature to help prevent users from saving to an existing file. When the user selects an existing file and clicks Save, the application automatically displays the dialog box shown in Figure 5. You don't need to add this functionality; it comes as part of the dialog box. Of course, there's a property setting you can change, OverwritePrompt, if you want to override this behavior. Simply set the OverwritePrompt property to false and the user won't see any overwrite warnings.

Figure 6. The user isn't allowed to save to a read-only file.

If the user tries to overwrite a read-only file, the application automatically displays a second message, as shown in Figure 8-6. In this case, the user isn't given an opportunity to bypass the protections. There isn't any way to override this behavior programmatically, either, unless you create an event handler for the FileOK event. You'd need to detect the file the user has selected, change the file's read-only status, allow the save to progress, and then change the file's status back to read-only. This could be a helpful technique if you want to allow the user to write data to a file and then disallow changes to that file later except under certain conditions controlled by your application.