Just Because Prince Wanted to Party Like it was 1999 Doesn’t Mean Your App Should
If you’ve ever used WPF’s OpenFileDialog control you have probably noticed that its appearance leaves a great deal to be desired. In particular the blocky, low res icons in the toolbar to the upper right, and the chiselled “classic” looking Open and Cancel buttons and File Name and File Type combo boxes at the bottom of the screen look out of place, especially on Windows Vista.
In contrast here is the appearance of the OpenFileDialog in Windows Forms 2.0 on Vista (shown below). The blocky icons have been replaced with something much nicer, and the buttons and dropdown combo boxes are displayed using the correct windows theme:
The default Windows Forms project template in Visual Studio 2005 includes a call to Application.EnableVisualStyles() which causes controls to adopt the “visual style” of the OS. Removing this call makes windows forms OpenFileDialog look the same as the WPF one – in short, it seems like this is a theme-related issue in a “pure” WPF application!
Microsoftie Bombay Boy (probably not his real name) explains how to work around this in WPF Clickonce applications by including an entry in the application manifest file. This was the way of creating “theme aware” Windows Forms applications for XP in .NET Framework 1.0. In framework 1.1 the EnableVisualStyles method mentioned above was added to the Windows Forms Application object. Although this entry suggests calling EnableVisualStyles as a way of getting around theme-related issues in WPF/WinForms composite apps it does not seem to fix the themeing issues with the OpenFileDialog. EnableVisualStyles seems to have been implicated in a number of subtle bugs also, so the manifest route may be the most robust approach regardless.
What about XBAP applications?
Fortunately since they are hosted inside IE (which essentially has something equivalent to what is in the manifest file, requiring the theme-aware MS Common Controls v6 instead of v5) there is nothing that needs to be done for them to get a more modern-looking OpenFileDialog.
What About Vista?
Although being able to change the appearance of the OpenFileDialog to give it a more modern appearance is a step in the right direction the current OpenFileDialog for both Windows Forms and WPF leave a great deal to be desired on Vista. For Vista, Microsoft made a number of improvements to this “common” dialog control to make it more like a miniature version of Windows Explorer (which also received numerous improvements). Compare and contrast the WPF and WinForms dialogs above to the following OpenFileDialog from none other than Notepad which uses the "system" OpenFileDialog on Vista.
The easiest way to get this open file dialog for your WPF applications running on Vista is to use the sample code provided with the windows SDK as part of the “Vista Bridge” sample – which is in the Cross Technology Samples zip file, which is installed by default to here: C:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\. The VistaBridgeLibrary project includes a CommonOpenFileDialog control which has an API similar to WPF’s built-in Microsoft.Win32.OpenFileDialog, it’s not quite a drop-in replacement but is fairly easy to use and also exposes some of the newer features of this dialog. The catch is that since this is a wrapper around un-managed API calls it will only be available to programs running with full trust (so NOT XBAPs).The Vista Bridge also contains a number of other interesting wrappers around un-managed parts of Vista and should be the first port of call for managed code developers looking to gain access to features of Vista if they are having difficulty.
I think it is a great shame that WPF, a platform that was developed primarily for Vista, could not provide built-in access to the system file dialogs. I hope the WPF team consider addressing this issue in the next release.
mysql – SQL: Unsual names – | Nathaniel