Jaa

Looking back to understand the future: OpenFileDialog vs. FileOpenPicker

  • Artikkeli

Most of us are familiar with the standard .NET OpenFileDialog object. With the introduction of Windows 8 Store apps the OpenFileDialog has gotten a facelift, a simplified API and yet somehow it’s still not quite the same. The new FileOpenPicker (or Picker) has been the subject of much mystery and confusion on the MSDN forums. What helped me get my head in the game was to compare and contrast the new and old. In this article I’m going to try and do just that.

I’m not going to talk about the various other classic file dialogs (IFileOpenDialog, GetOpenFileName, CFileDialog etc.). All of these APIs are very similar in functionality (keep in mind that all of these classic APIs are just incremental improvements over the file dialog box we had in Windows 3.1). So for simplicity I am going to stick with comparing the widely used OpenFileDialog object with the new FileOpenPicker.

 

File Open Dialog

 

File Picker

Similarities:
• They both enable a common UI to allow users to navigate their file storage space and select a specific item(s).
• They both allow filtering to limit the types of items.

Differences:
• The OpenFileDialog allows for UI customization. The FileOpenPicker does not.
• The OpenFileDialog returns a canonical path that represents the file that was selected.
• The FileOpenPicker returns a StorageFile object that represents the resource that was selected.

The key takeaway here is that both the FileOpenPicker and the OpenFileDialog accomplish similar tasks (i.e. allow the user to select something). The big difference is what gets returned.

When the FileOpenPicker returns, it hands you a StorageFile object. Unlike the standard file path we all know and love, the StorageFile object isn’t a pointer to a file. The StorageFile object is a pointer to a broker that points to some resource.
 
A broker is a software agent that is able to access a system resource on the behalf of the user. In other words, the user gives permission to the broker to access the resource via the FileOpenPicker. The broker then hands you a StorageFile object that represents the resource.

A resource can represent any digital data and can be located locally or remotely. In other words, a resource represents a data stream that could be located anywhere. It could even be generated. Just to try and drive this home; the standard canonical file path that we expect from our file open APIs doesn’t really exist in the Picker paradigm.

 

API mapping:

FileOpenPicker

OpenFileDialog

ViewMode

Options

SuggestedStartLocation

InitialDirectory

SettingsIdentifier

Instance

FileTypeFilter

Filter

CommitButtonText

N/A

PickSingleFileAsync

ShowDialog

PickMultipleFilesAsync

Multiselect + ShowDialog

You can follow me @DevDailey and my team’s hashtag is #WSDevSol. Talk with you in the forums.

Comments

  • Anonymous
    December 11, 2012
    Why is it that we cannot pick multiple folders in the folder picker? Why does the file picker takes a serious amount of time to select many files and displays a circle progress? And whats the best way (resource wise) to select about 40K files from a folder and its subfolders? Calling getFilesAsync(index, 100) in small steps still quickly increases the runtime brokers memory consumption up to 5 GB!

  • Anonymous
    September 04, 2014
    The FileOpenPicker is a big step back. Especially search in long filelists (imagelist) is nearly impossible. No chance to use wildcards. No quicksearch with firstletter. The so called intelligent zoom does not work. Try a list of images, pinch to zoom. You get a list of letters. Now you choose a letter. I expect, that the part which is shown begins with the chosen letter. Nothing. Do you know a possibility to get this important features. Do I have to write my own fileopen-class?