May 27th, 2020

The SetClientGuid method of the common file and folder dialogs lets you give names to those dialogs, too

Raymond Chen
Raymond Chen

We saw a little while ago that the SettingsIdentifier property of the various file pickers lets you give names to your pickers. Those work for the Windows Runtime pickers, but what if you’re using the old-fashioned Win32 pickers?

There is an analogous feature in the Win32 file and folder pickers: You can call the IFile­Dialog::Set­Client­Guid method with a GUID that names your dialog.¹ As before, you can use different GUIDs for different scenarios in your program, and each of those scenarios will retain their settings separately.

The IFile­Dialog is a base interface of both the IFile­Open­Dialog and IFile­Save­Dialog interfaces, so you get this functionality in file open and save dialogs, as well as the folder picker dialog, which is just a file picker that has been configured with the FOS_PICK­FOLDERS option.

On the Win32 side, you also have the bonus method IFile­Dialog::Clear­Client­Data() which tells the system to forget the settings that were associated with the client GUID. The next time a dialog with that GUID is displayed, it will show up with the defaults.

¹ Unlike the Windows Runtime case, where names from different apps are kept separate, in the Win32 case, the GUID is kept in a global namespace, so make sure to use some GUID unique to your program, rather than some value that might collide with one chosen by another program.²

² On the other hand, if you have multiple programs that work together, you might intentionally use the same GUID in all of them, so that they share state. For example, if you have a suite of programs that all have an “Export as Contoso Archive” command, maybe you want them all to export to the same place.

Category
Old New Thing
Topics
Code

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

5 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest Popular Oldest
  • Bas Mommenhof

    How would this work with the vanilla file-dialogs provided by System.Windows.Form (SaveFileDialog/OpenFileDialog)?

    These dialogs do not implement the IFile­Dialog but are wrappers around hidden classes (FileDialogNative.FileSaveDialogRCW) that do.

    Does that mean that if I desire this behavior, I should roll my own dialogs?

      • Bas Mommenhof

        Helpful, thanx.

  • n/a n/a

    I have to play with this. Thanks.
    Since W10, the save dialog has a stupid bug for me.
    In all previous Windows versions, I can paste a path to the filename, press “return” and the path is changed and the original filename appears again.
    This worked also when I was already in the path I pasted. Since W10, nothing happens, the path is not removed and replaced with the filename.

  • Joshua Hudson

    Bonus Content: GetOpenFileName/GetSaveFileName don’t have names, but you can do it yourself. When calling the explorer-style dialog boxes, you can pass a directory name as a filename and it will prefer that directory to the saved default location.

    You can’t do this with the old-style dialog boxes (why use old style? server core documents components used by explorer-style dialog boxes as unusable) though. It will malfunction.

Read next