Different behaviour of FileChooser.browseForFileToSave


#1

Depending on the platform, I get various behaviours when using browseForFileToSave(true) with a file filter that specifies a given extension (let say '*.mid' )

On windows and macos, if I manually enter a file name that has no extension (let's say "foo"), getResult() will return a filename with that extension added (it will return "foo.mid"). Moreover it will warn if an existing "foo.mid"  is about to be overwritten.

On linux, or with the Juce-supplied file browser component, getResult() will return a filename that does not have been completed with the expected file extension (it will return 'foo' instead of 'foo.mid'). And the overwriting test will trigger if a file name 'foo' exists, not if a file named 'foo.mid' exists.

Another remark: the warnAboutOverwritingExistingFiles is always considered as true on macos, there is no way to disable it.


#2

Yeah, this is largely down to the behaviour of the various native file-choosers. If I was to try to make it more uniform, I'm not really sure what I'd change. And in fact having the juce file-chooser more flexible in allowing you to specify your own file-ending is actually quite helpful.

Another remark: the warnAboutOverwritingExistingFiles is always considered as true on macos, there is no way to disable it.

Yup. Don't think there's an option for that on OSX. (But if anyone does know how to do it, let me know and I'll implement that!)


#3

I have the same problem. I guess everyone does? How are people getting around it?

I need to make it impossible to save a file with anything other than my correct filename extension. But it is only a problem on linux.

I guess I could check the returned filename for the presence of the extension and add it if required, but I think that will break the overwrite warning… is there a better way?

Also, on linux the OS inserts the users username into the filename box! - very odd behaviour why would anyone want that?