Site navigation

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