locked
How to open/select a file by FileOpenPicker from AppData local folder?

    Question

  • My customized data was stored in Windows::Storage::ApplicationData::Current->LocalFolder->Path

    Later I need to open this file by FileOpenPicker. The problem is that I can only set

    openPicker->SuggestedStartLocation = PickerLocationId::DocumentsLibrary;

    but not my ApplicationData folder.

    Any solutions?

    The related trouble is that I can save a file to DocumentsLibrary but can not read it right.


    Charlie Chang L

    Thursday, August 2, 2012 6:18 PM

Answers

  • I need users to create and save their own database and then open later. That is a normal use.

    This sounds like the database is essentially a document file, in which case the Documents folder (or other user-specified location) is the right place to put it. You may need to modify your code to factor out the file access and allow you to pass in a stream rather than directly touching the file.

    The database should only be in the app data folders if it is internal to the app: the user wouldn't need to know where the database was or interact with it in any way outside of the app. The app could itself manage multiple databases and let the user name them, share or export them, etc.

    --Rob

    • Marked as answer by Charlie C Wednesday, November 7, 2012 5:05 PM
    Monday, August 6, 2012 9:21 PM
    Owner

All replies

  • You can't target the FileOpenPicker to your local app data folder, and few users will even know those folders exist to try to navigate there. The app data folders are for app-centric files that the user isn't generally aware of. The file open picker is to pick a file that the user is directly concerned with.

    You shouldn't have problems reading a file you saved. Once the user has granted access to the location, the app can use the AccessCache classes to store that permission. This is demonstrated in the File Access sample.

    --Rob

    Thursday, August 2, 2012 7:49 PM
    Owner
  • You shouldn't have problems reading a file you saved. Once the user has granted access to the location, the app can use the AccessCache classes to store that permission. This is demonstrated in the File Access sample.

    --Rob

    Thing is not as simple as on paper. Actually I worked on SQLite 3.17.x that was declared compatible to Windows RT. When I create a new database file in my Documents folder, the file name was created but the content is zero. But when I set the folder to my local ApplicationData folder, everything was fine. Because SQLite is in C code and may have applied standard file operations, the RT setting may have been not valid. I also tried AccessCache by Add(file), it still not worked. I have no idea how to set Documents\MySite\MyProg as accessible. I am running program in the debug mode under VC++ 2012.

    What the document may be right for pure Metro C++ but may not be right for Mixed C++/C.


    Charlie Chang L

    Friday, August 3, 2012 4:28 AM
  • Is your database file something that the user should be aware of? I wouldn't think so.

    If not, then you wouldn't ask the user where to put it with a FilePicker. You would just put it directly in your local storage.

    If SQLite needs to talk directly to the file system with C-runtime functions (fopen, etc.) rather than working with streams from a StorageFile then the database must be in the application data folders. Those are the only folders that the app has native write access to.

    If you create the file in the documents folder then the app does not have direct access to that file. It can get brokered access through a StorageFile: the broker process will handle the actual file access and will provide the app a stream which it can read and write to. There is no way for the app to directly access paths in the Documents library (or anywhere else outside of the application data folders).

    --Rob

    Friday, August 3, 2012 8:36 PM
    Owner
  • Is your database file something that the user should be aware of? I wouldn't think so.

    If not, then you wouldn't ask the user where to put it with a FilePicker. You would just put it directly in your local storage.

    If SQLite needs to talk directly to the file system with C-runtime functions (fopen, etc.) rather than working with streams from a StorageFile then the database must be in the application data folders. Those are the only folders that the app has native write access to.

    If you create the file in the documents folder then the app does not have direct access to that file. It can get brokered access through a StorageFile: the broker process will handle the actual file access and will provide the app a stream which it can read and write to. There is no way for the app to directly access paths in the Documents library (or anywhere else outside of the application data folders).

    --Rob

    I need users to create and save their own database and then open later. That is a normal use.

    Under the limitation of Windows RT I can not use Documents folder and have to write my own FilePicker. This is a huge limitation for Windows 7 programs. Many old C++ IO codes needs to be rewritten in Storage API or they can only access AppData.

    Are there any FilePicker like samples that allow me to create/open/save a file in Application Data folders?


    Charlie Chang L

    Saturday, August 4, 2012 5:45 PM
  • I need users to create and save their own database and then open later. That is a normal use.

    This sounds like the database is essentially a document file, in which case the Documents folder (or other user-specified location) is the right place to put it. You may need to modify your code to factor out the file access and allow you to pass in a stream rather than directly touching the file.

    The database should only be in the app data folders if it is internal to the app: the user wouldn't need to know where the database was or interact with it in any way outside of the app. The app could itself manage multiple databases and let the user name them, share or export them, etc.

    --Rob

    • Marked as answer by Charlie C Wednesday, November 7, 2012 5:05 PM
    Monday, August 6, 2012 9:21 PM
    Owner