locked
FOpen, FRead, FWrite, FClose Replacement...

    Question

  • Hello Guys!!

         My new game Core was in road, everything working fine. I've create a wizard to start my program, but for the publish it's gonna be for later Static LIB seem to not work with Using Namespace. Anyways, that not the point for the moment.

    I've some problem with _wfopen_s in write mode. Oki Windows Apps have new rules. let's resume:

    1. I can read from Appx Folder and subfolder.

    2. I Cannot write to Appx Folder and subfolder. (current problem, no place to save... must review #3)

    3. Some forum rules says: you must past by Windows.Storage.ApplicationData.Current.LocalFolder to acces to write (thru IStorageFolder)

    4. Other path need the Runtime Broker to CreateFile for you, must use async IO. (non-async way?) or inside (async operation + operation complete)


    Now if i will convert to Metro style (IStorage Runtime), which function who can replace FWRITE/FREAD And does it's possible to be in binary file mode?

    Just find Text mode and xml style (add key)... need to read or write in integer or a float.



    Friday, May 9, 2014 4:32 AM

Answers

  • Your summary seems fairly correct. See File access and permissions .

    You can use C runtime functions such as fopen, etc. in your app data (read/write) and install (read only) folders.

    The app doesn't have privileges to use other locations and will get access denied.

    If the user has granted privileges (either through library capabilities or a picker) the app can get brokered access to other locations via a StorageFile or StorageFolder object. These objects will provide a stream to the app. The app can use binary data with the stream and is not restricted to text data.

    --Rob

    • Marked as answer by Anne Jing Friday, May 16, 2014 2:05 AM
    Friday, May 9, 2014 5:16 AM
    Moderator
  • You can use standard file I/O and most Win32 file I/O functions in the areas you have direct access to as you note.

    You can only write to file paths that have one of the following 'root' paths:

    Windows::Storage::ApplicationData->Current->TemporaryFolder->Path->Data()

    Windows::Storage::ApplicationData->Current->LocalFolder->Path->Data()

    Windows::Storage::ApplicationData->Current->RoamingFolder->Path->Data()

    All brokered locations require you use WinRT IStorageFolder APIs because it may not actually be a local file on the disk (it could be cloud, webpage, network etc.). That said, you can just use the CopyAsync API to copy from the brokered location to a temp folder location and then use standard file I/O APIs to parse it. See the sample code under "Windows Store apps" on these two pages:

    https://directxtk.codeplex.com/wikipage?title=DDSTextureLoader&referringTitle=DirectXTK

    https://directxtk.codeplex.com/wikipage?title=ScreenGrab&referringTitle=DirectXTK

    You may find this article useful as well:

    http://blogs.msdn.com/b/chuckw/archive/2012/09/17/dual-use-coding-techniques-for-games.aspx


    Tuesday, May 13, 2014 6:32 AM

All replies

  • Your summary seems fairly correct. See File access and permissions .

    You can use C runtime functions such as fopen, etc. in your app data (read/write) and install (read only) folders.

    The app doesn't have privileges to use other locations and will get access denied.

    If the user has granted privileges (either through library capabilities or a picker) the app can get brokered access to other locations via a StorageFile or StorageFolder object. These objects will provide a stream to the app. The app can use binary data with the stream and is not restricted to text data.

    --Rob

    • Marked as answer by Anne Jing Friday, May 16, 2014 2:05 AM
    Friday, May 9, 2014 5:16 AM
    Moderator
  • You can use standard file I/O and most Win32 file I/O functions in the areas you have direct access to as you note.

    You can only write to file paths that have one of the following 'root' paths:

    Windows::Storage::ApplicationData->Current->TemporaryFolder->Path->Data()

    Windows::Storage::ApplicationData->Current->LocalFolder->Path->Data()

    Windows::Storage::ApplicationData->Current->RoamingFolder->Path->Data()

    All brokered locations require you use WinRT IStorageFolder APIs because it may not actually be a local file on the disk (it could be cloud, webpage, network etc.). That said, you can just use the CopyAsync API to copy from the brokered location to a temp folder location and then use standard file I/O APIs to parse it. See the sample code under "Windows Store apps" on these two pages:

    https://directxtk.codeplex.com/wikipage?title=DDSTextureLoader&referringTitle=DirectXTK

    https://directxtk.codeplex.com/wikipage?title=ScreenGrab&referringTitle=DirectXTK

    You may find this article useful as well:

    http://blogs.msdn.com/b/chuckw/archive/2012/09/17/dual-use-coding-techniques-for-games.aspx


    Tuesday, May 13, 2014 6:32 AM