BrowseForDirectory cancel callback

[d.healey]

Could we have a method to check if the user pressed the cancel button?

My purpose for this is I don't want the user to be able to open one file browser until they've closed another, I do this by setting a flag when the browser is opened and resetting it when it's closed, but I don't have a way to detect if it's closed by clicking cancel.

[d.healey]

@Christoph-Hart I thought of a possibly less intrusive implementation. What about if the callback is always triggered, regardless of if a directory is selected or the cancel button is clicked, and if the cancel button is clicked it returns false in place of a directory?

What do you think? I could probably implement this myself.

[d.healey]

Or a much more better solution! Only allow one file/folder browser to be open at a time... with a switch for strange scenarios where people want more than one open at the same time for some reason.

[d.healey]

So I've implemented the only one file browser at a time solution - https://github.com/christophhart/HISE/pull/657

As I wrote in the PR comments, I can't think of a reason you would want more than one open at a time, but I can think of situations where the user would spam a button on the UI and open lots of file browsers.

While I was poking around in the code I saw that it's very simple to modify it so that the callback will still trigger if the cancel button is pressed - I wonder if this would be useful for anything?

[d.healey]

I found another situation where I wanted to find out if the user had pressed cancel, so I went ahead and implemented it. https://github.com/christophhart/HISE/pull/701

If the user presses cancel it will return an empty file/directory. This is potentially a breaking change so perhaps it needs to be put behind a preprocessor definition.

What you need to do is within your callback check that the returned value is a file or directory before proceeding.

For example

if (!file.isFile())
    return Console.print("The user clicked cancel");

[clevername27]

@d-healey

1. Proposes the feature.
2. Documents the feature.
3. Codes the feature.

Because that's how @d-healey rolls.