FolderPicker: why isn't fileTypeFilter initialized by default?

Question

Hello guys,

I've noticed that using the FolderPicker object still requires me to specify its fileTypeFilter. Why isn't it already set to "*" (all files) or "." (only folders) by default?

thanks.

---

Luis Abreu

Answer 1

Hi,

You should set your specific fileTypeFilter for FolderPicker object. It's mainly used to secure file and folder access permission. You need to clarify what files you actually need.

---

Best wishes,

---

Robin [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

Hello Robin.

But when I use the FolderPicker, I'm interested in folders. In my opinion, I shouldn't have to specify any extension to get it working and it should just work if I instantiate it and show it without specifying the fileTypeFilter property (btw, the some thing goes for the fileopenpicker dialog).

one more thing: you don't get any decent error info which specifies that you need to set the fileTypeFilter and that means that new users will probably have a hard time understanding why instantiating the foderpicker and showing it ends up with an exception...

---

Luis Abreu

Answer 3

Uhmmm yeah, there should not even be a fileTypeFilter in the FolderPicker. Why is it there?

Answer 4

Even when using the folder picker, it is important to specify a fileTypeFilter so that Windows can filter out folders that don't contain the items your app is interested in. If the caller is a photo app working strictly with .jpgs and .pngs, it wouldn't be very useful to let the user select a folder that only contains .dat and .exe files. The caller is guaranteed that the folder they obtain has at least one file that is relevant to the app experience. It is required to specify a fileTypeFilter to ensure that callers carefully consider the user experience. It is, of course, possible to specify "*" and accept any file type but the user experience is tremendously improved if developers take the time to determine which file types can actually be operated on so that useless folders are not presented to the user.

Justin Cooperman

Answer 5

Hello Justin.

Yes, I understand the importance of having the fileTypeFilter property. What I don't get is 1.) why not have it default to . for folders and 2.) why doesn't the error message give any decent feedback about the error?

---

Luis Abreu

Answer 6

Hi Luis,

The fileTypeFilter must be explicitly set by the developer. There is no default for this property. The reason for this is essentially what I've described above: it is extremely important that developers consider this property when launching the File Picker. If the fileTypeFilter was an optional property that defaulted to "*", developers may not even realize it exists or simply ignore it.

To answer your second question, there is a very actionable error message. I've copy-and-pasted it below using the File Picker SDK Sample on the Consumer Preview. I think the issue you are experiencing with the error is that you'll need to scroll down in the VS error dialog window to see the entire message :).

Unhandled exception at line 72, column 13 in ms-appx://microsoft.sdksamples.filepickersample.js-8wekyb3d8bbwe/program.js
0x80004005 - JavaScript runtime error: Unspecified error
WinRT information: The FileTypeFilters property must have at least one file type filter specified.

Justin Cooperman

Answer 7

But Justin, wouldn't you agree that "0x80004005 - JavaScript runtime error: Unspecified error"

should actually be E_INVALIDARG instead of the generic E_FAIL?

Answer 8

Oh, there's a scroll bar...

and going back to the discussion, I know that this won't be changed, but I can't agree with this point of view. I really don't think specifying the files is that important when you use the *FolderPicker*. If I'm using the FolderPicker, then I'm interested in folders, not in files.

---

Luis Abreu

Answer 9

Luis, I am with you here. The Folder picker should not even display any files. It's totally confusing. You select a file and the folder is added to the basket. Then then commit button changes to "OK".

For the user the folder and file pickers look the same, yet behave totally different. Also there is no way to provide a descriptive text *why* the folder picker is display, with instructions for the user. So, this has to be shown before now in a flyout or or, and only after the explaination is closed by the user, the folder picker can be opened. Preferably without specifying any filter, so the user does not get confused. But then, the picker displays "there are no files or folders in this view". What?! There are files in this view, just none that match the filter.

This folder picker interface is totally confusing! Please change that!

Answer 10

Couldn't agree more :)

---

Luis Abreu

Answer 11

Justin Cooperman>

Even when using the folder picker, it is important to specify a fileTypeFilter so that Windows can filter out folders that don't contain the items your app is interested in.

Justin, I don't understand this reasoning plus it is not working like this when running the FilePicker sample app on RTM release.

When I choose the first scenario to pick a single file it has this in the code behind:

FileOpenPicker openPicker = new FileOpenPicker();
openPicker.ViewMode = PickerViewMode.Thumbnail;
openPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");
openPicker.FileTypeFilter.Add(".png");
StorageFile file = await openPicker.PickSingleFileAsync();

But I can select any folder, then I will see "There no files or folders in this view" message.

Also, limiting a folder picker with file extensions doesn't make too much sense  IMHO. What if an app needs to save a file to an empty folder ? 

You would not let to select that empty folder because it doesn't have a file with the predefined extension ??? 

Also, is it possible to create a new folder with folder picker ?

Thanks

---

tsabi