Windows File Dialog Custom Places in WPF 4

Pete Brown - 29January2011

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.

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.

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.

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

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?

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

Name (required)

Email address (will not be published) (required)

Website url

Remember me

Your comment is being submitted, please wait...

Your comment has been posted, thank you. (If your comment does not appear shortly, it was marked as spam.)

Pete Brown is a XAML and Blinky lights guy at Microsoft who focuses on Windows XAML (WinRT), WPF, Silverlight, .NET Micro Framework and other "code on the client" and "code on a device" technologies. This is his personal blog.
About Pete/Full Bio | Contact | About 10rem.net