The native windows FileChooser is broken since august

Windows
#1

The native filechooser cannot select a path which contains a non-ascii character, the string returned is an invalid utf8 string. It was broken by this change:

In order to test it: create a file with a non ascii character, launch the DemoRunner , choose dialogsDemo , select ‘native dialogs’, and then select the file.

1 Like
#2

This is maybe the issue I’m encountering here

#3

Thanks for reporting. The issue should be resolved by this commit:

1 Like
#4

Thank you reuk, it seems to work fine.

#5

That fixed the issue for our users as well.

#6

Well, apparently some users still have issues with this new FileChooser implementation, the window is not showing when it is created with a non-existing file path as the initialFileOrDirectory argument. This time, it is not related to unicode, this is just an issue triggered by the fact that the supplied folder does not exists. Unfortunately I cannot reproduce it, I have Windows 10 ver 2004. But it is confirmed to happen on the computer of a user having Windows 10 ver 1909.

When I revert the recent changes of the FileChooser by commenting the lines :

if (SystemStats::getOperatingSystemType() >= SystemStats::WinVista
    && customComponent == nullptr)
{
    return openDialogVistaAndUp (async);
}

it fixes the issue on his computer. So for now, I am going to do the same.

#7

Thanks for reporting, I’ve added a patch so that the FileChooser will fall back to the user’s Desktop folder in the case that the requested initial directory doesn’t exist:

1 Like
#8

I don’t know if this issue is related or I am doing it wrong. With Juce 6.0.5 on Windows 10, the FileChooser would remember the last location it selected a file. I moved to Juce 6.0.7 it now always defaults to the desktop even though I just opened a file in a different directory. i.e. it does not remember the last directory I opened a file from.


 juce::FileChooser chooser ("Select a .wav or .zip  file",
            {}, "*.wav; *.zip", true);

Running the same code on the Mac, it remembers the directory I last opened a file.

Thoughts?

#9

Bumping. I am running Windows 10 Build 19042 and Juce 6.0.7. Running the Juce examples, browsing for a file always defaults to the desktop instead of the last file opened location. Maybe I misunderstand, do I need to keep track of the last file opened location using FileChooser?

#10

This was an unintentional regression. It should be resolved by this patch:

Please let us know if you encounter any further issues.

1 Like
#11

Thanks @reuk

#12

I’m not convinced this change does what’s intended, at least not in Build 19042.928.

The test is fairly basic: if you set up multiple file choosers with different starting points with SetDefaultFolder being called, the first default path set will be the one used for any subsequent file chooser. Debugging in OnFolderChanging does catch the switch up…

As per the MSDN for SetDefaultFolder - https://docs.microsoft.com/en-us/previous-versions/bb775692(v=vs.85):

Sets the folder used as a default if there is not a recently used folder value available.

So, I’m not sure SetDefaultFolder is what’s needed here. For me, SetFolder (what was there before) does actually set the desired starting folder, regardless if a default one has been set.

BUG: win32 FileChooser ignores initialFileOrDirectory since recent commit
#13

I believe the current (patched) behaviour is consistent with the behaviour of the old-style dialog.

To test, I checked out JUCE 6.0.1 and ran the DialogsDemo, selecting the “Use Native Windows” toggle. I clicked the "‘Load’ File Browser’ button and selected a file in C:\Program Files. Then, I clicked on “‘Choose Directory’ File Browser”. The second browser dialog opens in C:\Program Files, despite the default directory being set to the current working directory.

I then ran the same steps on develop and observed the same behaviour, just with ‘new-style’ dialogs.

The state of develop atm is consistent with JUCE’s legacy behaviour, so I think it should probably be kept unless there are strong arguments to change it. Adding a new option to force a starting directory might be a good idea though, so I’ll add that to my backlog (although I can’t guarantee when I’ll be able to look at this).

#14

Ehh, I’m not really down with this even just based on the provided API.

initialFileOrDirectory the file or directory that should be selected when the dialog box opens. If this parameter is set to File(), a sensible default directory will be used instead. When using native dialogs, not all platforms will actually select the file. For example, on macOS, when initialFileOrDirectory is a file, only the parent directory of initialFileOrDirectory will be used as the initial directory of the native file chooser.

The gotcha on Windows isn’t listed there where a default will only be set once per runtime, regardless of what you set it to. To me, that makes the API rather useless. Why would I only want to set the default once this way? And how come I’m not allowed to overwrite it?

This “old logic” limits the control I need for varying dialogs.

#15

In terms of an example that’s not in some contrived test app:

  1. Start custom DAW, open project using a file chooser, set working directory/starting path to [...]/Documents/Something/My Projects. Works as intended.
  2. Import audio file using a file chooser, set working directory/starting path to [...]/My Music/. Woops! File chooser starts off in that My Projects folder.
#16

it should only happen if you set initialFileOrDirectory to empty File()

#17

Thanks for your patience, this has been sitting in my backlog for ages.

I’ve slightly tweaked the logic so that we’ll call SetFolder if an initial path is specified, or fall back to SetDefaultFolder if File() is passed. I think you’re right that this new behaviour is more consistent with the docstring for the FileChooser constructor.

As always, please let us know if this change causes any issues for you.

1 Like