Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Windows File Dialog Custom Places in WPF 4

Pete Brown - 29 January 2011

Starting with Windows Vista, the open and save file dialog boxes have a panel on the left side containing favorite links. These links are known as "Custom Places". Previously, the built-in Windows dialogs were available only if you used the Windows Forms versions. However, starting with WPF 4 on Windows 7 and Windows Vista support of native file dialogs with custom places via the FileDialogCustomPlace and FileDialogCustomPlaces classes can be found in the Microsoft.Win32 namespace right in the PresentationFramework dll.

Using Standard Custom Places

The framework includes a number of built-in custom places, representing the usual system and user locations on the machine, plus the local and roaming profile locations. To use them, simply use the static instances provided by the FileDialogCustomPlaces class.

private void SaveButton_Click(object sender, RoutedEventArgs e)
SaveFileDialog dialog = new SaveFileDialog();



When displayed, the dialog will have two custom places shown at the top left (refer to screen shot in the next section): the local application data folder and the templates folder.

The standard places supplied are (from MSDN) :

Name Description
Contacts Contacts folder for the current user.
Cookies Internet cookies folder for the current user.
Desktop Folder for storing files on the desktop for the current user.
Documents Documents folder for the current user.
Favorites Favorites folder for the current user.
LocalApplicationData Folder for application-specific data that is used by the current, non-roaming user.
Music Music folder for the current user.
Pictures Pictures folder for the current user.
ProgramFiles Program Files folder.
ProgramFilesCommon Folder for components that are shared across applications.
Programs Folder that contains the program groups for the current user.
RoamingApplicationData Folder for application-specific data for the current roaming user.
SendTo Folder that contains the Send To menu items for the current user.
StartMenu Folder that contains the Start menu items for the current user.
Startup Folder that corresponds to the Startup program group for the current user.
System System folder.
Templates Folder for document templates for the current user.

While the standard places will suffice for most applications, especially since they include the local application data folder, you may wish to provide additional locations. This is accomplished via the FileDialogCustomPlace class.

Adding Your Own Places

Sometimes the built-in places aren't sufficient for all the locations you'd like to surface to the user. For example, I have some software recording/sequencing applications. Many of those share the same folder for plug-ins, known as VSTs. I may want to provide the ability for the user to quickly locate that folder in the open and save file dialogs. This is accomplished by creating an instance of the FileDialogCustomPlace class.

private void SaveButton_Click(object sender, RoutedEventArgs e)
SaveFileDialog dialog = new SaveFileDialog();

string appSpecialPath = @"C:\Program Files (x86)\Image-Line\FL Studio 9\Plugins\VST";

FileDialogCustomPlace place = new FileDialogCustomPlace(appSpecialPath);




The FileDialogCustomPlace class constructor takes in either a string path or a GUID which refers to one of the built-in places. In this case, I supplied it with the VST plug-in folder. When run, the dialog looks like this:


Note that the name of the folder is displayed using normal Windows mechanisms: you get just the name of the final folder in the path.

Also note that on Windows XP, the custom places will have no effect. The feature is gracefully dropped.

posted by Pete Brown on Saturday, January 29, 2011
filed under:          

4 comments for “Windows File Dialog Custom Places in WPF 4”

  1. Mikhailsays:
    I have two questions/complains regarding WPF File Dialogs. 1. WPF File Dialogs are not shown in the Windows Taskbar. 2. If multiple File Dialogs are shown in succession then a double-click in the first would bring underlying, completely unrelated window into foreground (it will get focus) and successive File Dialog will be buried beneath of it. Because it is not being shown in the Windows Taskbar user is not aware that there is an another File Dialog waiting. If user knows it is still extremely difficult to find this hiding File Dialog because it is buried somewhere between two windows (users usually have many of them) and all windows have to be manually minimized. How this problem can be solved?
  2. rajeevsays:
    Hi Pete,
    i am creating a similar stuff. But where i have got stuck is in the name of the place bar (in your case, it is WpfCustomPlacesDemo). However, in my case , it is coming as vshost32-clr2.exe.

    Please guide me if you are aware how i can change this name to something else, as in your case.

  3. Someonesays:
    Any chance CommonOpenFileDialog from WindowsAPICodePack makes it into WPF classes ?
    I am tired of downloading DLLs from the web (or referencing WinForms) to get the job done.
    Also, it might be interesting if MS created a dialog that allowed you to select many folders and files at the same time. Sth like SelectFileSystemEntitiesDialog.

    Also, I hope you improve WPF and don't stick to these HTML apps. From my experience apps using HTML and Javascript are the buggiest apps ever. In fact I have yet to see a web page that works as it should.
    WPF is the best desktop apps technology created by MS ever. I hope it evolves accordingly.

    In WPF I had seen some cases where there where problems:

    1) There was a case that what I needed to do was only done in XAML, so I had to parse a XAML string to do my job. I find this rediculous. (I don't remember what that was)

    2) From my experience, when you make a control template that uses a static part, the styling doesn't work fine. E.g. I needed to make sth like a colorpicker and have the popup common for all colorpickers (why waste memory? Only one is open at a time.). I don't remember if I have generated my static popup in code or if I've managed to define it in XAML, but the styling didn't work and I had to invent very odd ways to make work. I don't know if I was doinf sth wrong. Perhaps I built the popup in code and I should do it in XAML? Anyway, it's hard to for me understand when the style is applied and when not.

    3) I have the impression that styles could be much more flexible than what exists now.

    4) I think that it would be possible to make controls to get inserted automatically at positions in a Grid with row and column definitions with specifying a Grid.Row="Auto" and Grid.Column="Auto". This could fill the grid row-by-row from left to right or with custom ways of filling it. It is very annoying to change indices to insert new things.

Comment on this Post

Remember me