I’m using FileChooser::browseForFileToSave() to save a file to disk.
When I select a directory which contains a previous save, “foo”, and call my new file “foo” as well, I don’t get the usual “The file ‘foo’ already exists. Do you want to replace it?” dialog from Nav Services.
Is there a flag I need to set to see this behavior? I’ve tried to get this to happen by entering the file name with or without the .xxx file extension, but it doesn’t seem to make a difference.
personally, i would have my own code handle the problem. I class the file choosers as simply ways of selecting a file, and what is done with the file happens as a result of my code. You can just check result.existsAsFile() and pop up your own alert window.
Yes, it’s not really the file chooser’s job to do that.
If what you’re doing could be done with a FileBasedDocument, it would do all that kind of logic for you though.
wow, how long has that one been there?? that’s an excellent one there! 
and i thought you’d stopped surprising me like that jules
It’s been there a while! It’s coming in very handy for the Jucer at the moment.
my Data classes will go nicely into it - i spent a while trying to come up with a good way of storing data in a way that made itself safe to access (and also able to notify of changes) that can be kept away from the GUI components, and ended up with ‘FileDataElement’… i did make a special ‘root’ element but that class wins over mine!
still, that makes it easier to adapt my classes to have a nicer general juce compatible solution. i really ought to put up a proper demonstration of those classes because they have made my life so much easier (and noone seems to care!). i’ll tweak the system to be based around a FileBasedDocument then maybe it’ll be easier to appreciate!
I think it’s better to have Nav Services handle issues arising from overwriting files on save. In that way, if a user chooses a name that already exists, the save dialog box doesn’t have to disappear and reappear.
And Navigation services already offers this functionality: you need to set the kNavDontConfirmReplacment flag to false. FileChooser::showPlatformDialog() is explicity turning that flag on when running dialogs, which explains why I was missing the warning.
I think the ideal JUCE solution would allow me to set the NavDialogCreationOptions (including the flags) before the dialog is run, then I can configure the interface to my liking. Might there be a way to do this in a future release?
there is a chance that such a ‘nav services’ thing is not present on the other platforms juce supports… i don’t know that of course, but it’s always a possibility and would be a fair enough reason to not have such a thing. i can imagine that even if a similar functionality were present in the other platforms, keeping the cross-platform-with-identical-code juce nature may be tricky if you’re exposing more things like that.
really, what is wrong with doing it yourself? as jules suggested, FileBasedDocument handles that kind of logic, and the chooser is literally just a chooser.
(incidentally, i don’t mean for the above post to read like i’m as much of a knob as it probably does)
