Glad to see the new version of the file dialogs with improved features, but they are still buggy.

Now the option for filters and file extensions were implemented, but there are some typos in the german version of the OpenFileDialog for example "Neuer ordner" instead of "Neuer Ordner" or "geöffnet" instead of "Öffnen".

Another bug seems to be that if you choose the details option for the content with an applied file filter you do not see the folders in the directory anymore.

Just a question: How can I expand the structure tree in the overview pane to the initial directory of the dialog? I didn't find any option for the startup location of the structure tree. 

Please fix these bugs ASAP so we can get rid of the default crappy Windows-dialogs. :-)

We are now evaluating the new FileDialogs.

1. It would be great if Network locations could be accessed.
2. Also Make New Folder functionality could be added

I am wondering if there is a chance to set default file extensions and filters for the dialogs. Without this option the dialog loses very many benefits against the Windows file dialog. 

Is there any strategy for implementing this feature in a later version or have I missed something?

 Best regards, Martin

+1 
In multiple window WPF apps, I had problems with both w32 and forms dialogs. Most notably when double clicking a file, the click goes through the dialog and cannot stop it... 
So looking forward for this control. 

David - I am using System.Windows.Forms and I continually have issues - the UI hangs

Giving this one a "Dislike".

Use the controls in System.Windows.Forms.  They work and I've never had a problem.  Those with problems are probably using the Microsoft.Win32 components directly and that's not the right ones.  There's a reason there isn't a "WPF" version of these in the WPF WindowsBase or PresentationCore to begin with..  It's because they already exist in System.Windows.Forms.  Why duplicate the effort?

Implementing custom versions of these would be non-trivial because they need to be able to handle things like security, allow the user to browse network locations, show the libraries which are different from actual directories, Favorites list, recent locations etc... Anything less and the user is going to have a bad experience and complain about your program.  That's an enormous amount of custom functionality that needs to be implemented.

The built-in controls also provide you with a consistent experience for the user as they see the same dialog that they see in every other windows program.  This is not something that you should be styling and changing.

using win32 OpenFiledialog in WPF has problems, it can and does sporadically hang your program.  It is well documented by many (google wpf openfiledialog hangs.


I bought this library to make sure I did not have to deal with plumbing ike this.

My only complaint about the stock dialog is the fact that it can't be styled.  If I could get a control that provided same functionality with wpf styling that would be perfect.

+1 because BrowseFolderDialog doesn't exists in Microsoft.Win32 and Microsoft.Forms references or P/Invoke work is needed.
A fully integrated styled component may also be a good thing instead of using an ugly-not-styled Microsoft stock component which is also a reason why we bought Telerik.

I was a little disappointed when I saw that I must use basic Microsoft stock components even if they do the job well enough.

+1 for like because reusing the components is a good argument, but it doesn't cover:

a) Styling. What if you want an Open/Save file dialog with a style consistent with the rest of your app?
b) Extensibility. 

I think this is a great idea. I found this thread because I had assumed Telerik would already have this control and was a bit disappointed to find out they didn't.

Reasons for Dislike:
1. Telerik is better than competition.
2. Reusing the Windows components.
3. Telerik controls based on Microsoft libraries too.
4. Win32 is very intuitive in this particular case.

Regards.