ofBufferToFile() not working

[steven-chith]

Testing load and saving some settings, and ofBufferFromFile(filename) works great(!!!). Super excited about that one.

But I can't get ofBufferToFile() to work. Here are the two functions:

// THIS ONE IS FOR LOADING, AND WORKS BRILLIANTLY (when the files are added to project ) void Interface::load(int index) { string fileName = "preset" + ofToString(index) + ".txt"; string text = string(ofBufferFromFile(fileName)); vector list = ofSplitString(text, " ");

if (list.size() == slider.size()) {
    for (int i = 0; i<slider.size(); i++) {
        *slider[i].value = ofToFloat(list[i]);
    }
}

}

// THIS ONE IS FOR SAVING, THOUGH AND _DOES NOT WORK_ void Interface::save(int index) { vector list; for (int i = 0; i<slider.size(); i++) { list.push_back(ofToString(*slider[i].value)); } string text = ofJoinString(list, " "); string fileName = "preset" + ofToString(index) + ".txt"; ofBuffer buffer = ofBuffer(text); ofBufferToFile(fileName, buffer); }

Stepping through the code for saving, all the variables are getting built out properly, and both filename ("preset7.txt" in this case (no additional pathing data required(?)) and the actual text string have correct information.

It get's passed to the ofBufferToFile(filename, buffer) as well, and no error is raised, but I can't find any file created anywhere.

Getting both loading AND saving to local cache would be great, even if we need to educate on saving 'only works to local cache, so future 'load' from there too? We need to think through and solve this as a WinRT 'best guidance / strategy' level.

[steven-chith]

Creating and writing files can only be done in an app's local directory or a temp directory that gets erased with each app's start. There's a special path to use to get to it, but I'll just modify the underlying file IO implementations to prepend the proper path for the local directory since that's closest to what users are probably expecting.

[steven-chith]

I forgot to consider this, but when people are reading from a file they can do it relative to where the app's executable is stored, but if we just add the app's local directory to the file path while writing they won't be able to open it for reading. So what I'm going to do is if the file can't be opened for reading it'll try again with the added path.

[steven-chith]

I got it to write files in the local directory and reading from there, too, if initial file reading fails.

[steven-chith]

Ok, I tested out the buffer writing and it works (which is awesome). But we really need to rethink the ordering of where we should save by default, and where we search as the alternate. Let's work back from a very common use case:

OF projects are in the "habit" of having a /data folder, where you add .txt or image files you want to load; like textures or in my test case, various "setting[n].txt" files you can swap out for testing parameters. This is the OF communities equivalent of our "assets" folders. So, I setup a VS project, I add a data folder, and I add two text files ( perhaps from another designer or project ) to test out and tweak some parameter settings.

When I publish my Windows Store app, mentally, I know that the text files in my "data" folder have magically followed my executable, so I can load them into an ofBufferFromFile() like this (note: I don't even need to specific "/data/" in the path, though if this becomes a requirement later, it will still be a mentally acceptable constraint):

string fileName = "setting1.txt"; // or "setting2.txt"
string text = string(ofBufferFromFile(fileName));

Now, I'll split that txt or xml, fill it into a toolbar or parameter controls, and start tweaking and tweaking and tweaking. At some point, I like what I tweaked more than the original default, so I want to over write the new settings into setting1.txt like this:

    string fileName = "setting1.txt";
ofBuffer buffer = ofBuffer(text);
ofBufferToFile(fileName, buffer);

CHALLENGE ----------------------------------

So how you implemented it now, by DEFAULT it will write this into my App cache here:

C:\Users\ricbarr\AppData\Local\Packages\116cad26-0464-463c-a521-2802893rb000_xdytb6at8c9v0\LocalState

But what it doesn't do is replace the file in my apps executable path ( what, in my head is the original /data/settings1.txt file). It will only look for my updated (second instant of) "settings1.txt" file in the LocalState if I explicitly delete the original data/setings1.txt file.

I tested that, and it works great.

I'm wondering if we should actually FIRST try and save to the local /data/ and also FIRST try to read from the local /data/ filter OF projects use by tradition, and barring the file being found there, THEN go to LocalState?

Otherwise, we are changing the way we are asking OF devs to think about their data folder ( it is now only read only, and saving and editing go to LocalState first, but you can't prepopulate LocalState from the IDE, which is where the "usability" problem occurs.

NOTE: Saving the Image object to the Pictures directory, though, does NOT have this same mental usability problem, though, since Image generation is usually generated from SCRATCH, and it is perfectly acceptable to let them know on Windows Store, you will look for the OUTPUT there in your Pictures folder. But dealing with Data files more often then not - you share or swap them, load them in your IDE and tweak them before compiling, load them at run time, tweak them in the IDE and then expect to write OVER them as you refine your settings and parameters.

Thoughts?

[steven-chith]

The files in the app's install directory are read-only. My first thought to try to save to the original directory, too. Unfortunate, but the devs will have to manually overwrite those files themselves.

[ghost]

P2- please investigate the current behavior for iOS

[steven-chith]

So for iOS's file IO they acknowledge the sandboxed environment by having an addon for iOS that returns the path of the user's documents folder where they rely on the user to prepend it to the file name. We could do the same thing, but it requires the dev to declare what file extensions are allowed. iOS requires no such restriction. The current method we have now doesn't require any file types declared.

[stammen]

Rick, do you think the current behavior is acceptable?