Can you please add the ability to select (and scroll into view) a file/folder in the RadFileDialog by keyboard? i.e. when focused within the files section of the dialog, typing 's' should scroll to the first file starting with 's' and select it.
All the Win32 and WPF file dialogs support this.
Currently RadFileDialogs do not provide such tooltips when hovering files and folders. Check the attached image for clarification.
Currently, showing a dialog can take 10-20 seconds when started in DEBUG mode. And 3-5 seconds RELEASE mode. Improve the loading time. A little way to speed up is to set ExpandToCurrentDirectory to False.
This might be a public event (File/FolderSelecting) or property (IsSelectable) of the FileSystemInfoWrapper but user will need a mechanism to set it (control over the file/folder wrapper creation). For example some files might be visible and not filtered in main pane but should be disabled for user selection.
For example user might need to show files in FolderDialog or filter the folders somehow in all dialogs. Currently this could be achieved with custom style for OpenFolderDialogControl, binding the ListBox to CurrentParentDirectory.Children and use converter. By default this binding is to CurrentFileSystemObjects.
Like in MS Win 32 OpenFileDialog - thumbnails with preview or details about the selected file. Check the attached images for better clarification.
Add a full autocomplete support - while the control is focused, type certain keys and the file dialogs should select the relative match for the currently typed text.
Currently mobile phones are not visible in the navigation tree of the file dialogs.
Make them available like in MS Explorer and file dialogs.
It would be nice to create a seamless experience for our users between an application that uses the RadFileDialogs and their native Windows OS. To that end, having the RadFileDialogs use the same InitialSelectedLayout as the base OS would go a long way. Adding some way to identify the current Windows setting and to set the RadFileDialog accordingly would be a great help.
It appears that the display string is the last element of the path, but this can cause potential confusion when the paths are very different, but the last folder is identical. Take for example "C:\Users\Public\Documents" and "C:\Users\<user_name>\Documents". Each of these will be displayed as "Documents" in the final UI, even though the first is probably more recognizable as "Common Documents" or "Public Documents". The icon appears to be different for each, but that's not enough to distinguish them enough without first browsing the path.