FileChooser() does not match files in Xcode 9.2

I’m now building a simple UI app under Xcode 9.2 and had to raise the minimum deployment target to 10.9 to avoid deprecation warnings.

FileChooser() no longer shows any matching files for my string “my-file-.bin;my-file-.jco”. It shows all files okay if I change this to “.”.

In I can make it work by commenting out the first line below and using #if(0) to force use of the deprecated older code:

#if (0)
[panel setDirectoryURL: createNSURLFromFile (directory)];
[panel setNameFieldStringValue: juceStringToNS (filename)];

    if ([panel runModal] == 1 /*NSModalResponseOK*/)
    if ([panel runModalForDirectory: juceStringToNS (directory)
                               file: juceStringToNS (filename)] == 1 /*NSModalResponseOK*/)

I don’t seem to be able to debug into [panel runModal] so can’t see any deeper into this at the moment.

BTW it also fails to match any files if I only have one matching pattern “my-file-*.jco”.

For now I can change the deployment target back to 10.5 which makes it work, and put up with the deprecation warnings, but it would be nice to get a fix for this which avoids warnings.

That bit of code I copied has lost its asterisks, the search string is my-file-.bin etc.

Hmm, even that didn’t show - there are asterisks before the extension!

To paste code start and end with 3 tilde (~) characters

// code goes here


Thanks - I shall check out the markup language for next time - meantime I think the post showed the problem with FileChooser on Xcode 9.2 okay. Temp workaround is to build for OSX 10.5 and to live with the deprecations…

Annoyingly, the newer file browser functions provided by Apple only support selecting files by extension - there’s no way to filter by any other part of the filename.

I’ll update the documentation and add some assertions to make this clearer.

Okay, thanks for looking into it. I’ll probably stick with the 10.5 target deprecations for as long as they still build. If Apple removes support completely I suppose I’ll have to work around in the application code. Maybe by then the functionality will be added to the new native API anyway.

I believe the assertion you added is not strict enough:

jassert (filters[i].indexOf ("*") <= 0);

Still allows filters to be invalid, for example "*a.txt" or "*.a*".
These are very uncommon but why not implement it to mean exactly what is supported, so:

jassert (filters[i] == "*"
         || (filters[i].startsWith ("*.") 
             && filters[i].lastIndexOfChar ('*') == 0));

Thanks for spotting - I’ve made the check more robust.

FWIW since you can still filter on file extension, we’ve decided that that is adequate - the additional filter on part of the filename was quite handy as it allowed us to exclude files for other applications that also use our specific extension, but not essential.

So we’re now building for >= OSX 10.9 to match any name with the desired extension, and as t0m says, that works fine, and we have no deprecations. Thanks, all.