Different behaviour of FileChooser.browseForFileToSave

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.

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!)

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?

The issue is still present in 2020, checked both with JUCE 5.x and JUCE 6.x. In addition to what @jpo said:

  • Windows 10: if the pattern is only one (e.g. *.jpg), the file chooser appends that extension to the output path. With more than one pattern (e.g. *.jpg;*.png ), it just returns the plain string as in the Linux non-native chooser;
  • macOS 10.14: it always uses the first pattern as the extension to append, even if there are more than one allowed.

So the safest thing to do for now is to check the presence of the file extension whenever you call FileChooser.browseForFileToSave() and add it if it’s missing. A uniform behavior would be nice…

1 Like