I am using a Native FileChooser to save and load files. I want to open the FileChooser in the most recently used directory by any previous FileChoosers AND pre-populate the FileChooser file name field. I have been able to satisfy both of these constraints separately but not together.
1. FileChooser opens most recently used directory
FileChooser myChooser ("Save a File");
if (myChooser.browseForFileToSave(true))
// Save the file . . .
In this instance, the constructor for FileChooser chooses a “sensible default directory” (as explained in the constructor documentation) and has the most recent directory behavior I want. The next FileChooser I open will open in the last directory used by the previous FileChooser. This is the behavior I want for directory placement.
2. FileChooser has pre-populated file name
File filePath;
filePath = filePath.getChildFile ("MyFile.txt");
FileChooser myChooser ("Save a File", filePath);
if (myChooser.browseForFileToSave(true))
// Save the file . . .
In this instance, my FileChooser always shows the root directory with the pre-populated file name “MyFile.txt”. So the full path is /MyFile.txt. This behavior totally makes sense to me, because that is the path that I gave to the FileChooser. But, is there a way for me to load a FileChooser to have a pre-populated file name in the most recently used directory?
I have only run my JUCE program on Mac.
In the JUCE source code, I was unable to find where the FileChooser's constructor parameter initialFileOrDirectory gets converted from a default File() to this magical recently used directory that I am looking for. I thought there might be a File::SpecialLocationType for this, but was unable to find it.
Still, at the moment, we can only keep track of directories if FileChooser::getResult () has returned true.
I think having a FileChooser::getLastUsedDirectory () method would be very useful for this kind of situation.
I guess it’s a personal preference as to whether this is needed as part of the JUCE implementation. I have this feature in all of my applications that deal with opening/saving, and I just implement it myself. It is super simple to do by saving the path of the file returned from the dialog, and using that in the next invocation of the dialog.
I also often make it a persistent piece of data by storing it in an application prefs file, if that makes sense for the work flow.
Do you keep track of the path even when the file chooser dialogue returns false (i.e. the cancel button has been pressed) and therefore FileChooser::getResult () returns an invalid location? If so, how?
Oh, I see I had glossed over that part of your question, my apologies. From a user perspective, I think this is uncommon, but I can see how it might be useful. On Windows you can capture the dialog events to do that. Assuming it’s possible on the other OSes, it might be an interesting option for JUCE to provide.
[edit] I just checked and this is not possible on the mac. It is considered a privacy issue, “The macOS APIs are explicitly designed to respect user intent and privacy. When a user cancels the dialog, the system ensures that no data about the selection is made available to the application.”