UX: Does it make sense to always close Open/Save Dialog when clicking the action button?

Been working a lot with OpenDialog, and noticed that when clicking the ‘Open’ button, the dialog always closes, regardless of the state of the selector window. Looking at the source for the button, it is hardwired to just say it’s not canceled and immediately close the dialog when this button is clicked. As someone who works with users and UX a lot, does this make sense? On these dialogs (open/save) there is two options: Cancel and (Open/Save (I’ll call it the action button from here on out). Clicking cancel will immediately close the dialog and say it was canceled. But clicking the action button at any time also will close the dialog, regardless of whether the select item(s) are actually valid.

Does this make sense, from an end user perspective? I get that the developer can check the result of the dialog, to see if it matches what they expect. But from an end user perspective, does this dialog behave like one would expect? In my testing and use of the library, it doesn’t seem to feel like it - if I have a file selector for example, I can still click open on a folder that is highlighted. On other platforms (such as Windows) clicking ‘Open’ when in file chooser mode, when a folder is selected, makes it open the folder (navigate into it). In folder chooser mode on windows, clicking ‘Open’ on a folder opens that folder, and having none selected opens the current folder (which if I recall is how this library currently behaves in folder mode now).

I know having a button dedicated to closing dialog is good, but that is already handled by the cancel button. I feel like if the user selects the action button, there should be a valid result set on the dialog’s variables (FilePath/FilePaths), as part of the API agreement: Open a dialog and get me a valid (filepath/folderpath)(s), OR get me nothing if the user cancels. Right now it is Open a dialog and maybe get me a valid file/folderpaths, OR get me nothing if the user cancels. Maybe this is by design, but it seems weird having a dialog that opens file browser but can return invalid results. I get it is still up to the dev to check the results, because users be users.

I wrote some code to test if the selection was valid, but I did not commit or make a PR for it as I was not sure if this was intended behavior. As I am somewhat of an ‘end user’ of this library, I think the file selection behavior seems a bit… off, maybe not totally incorrect. In my local code I had, I made a new method that checked if the selection was valid in FileDialog, based on if it was a OpenDialog or a SaveDialog (as it seems the base dialog has no way of knowing what kind it is, I just used a if (this is OpenDialog). I got it to work for single file selection, but I wasn’t sure how to handle multi file selection (I don’t use this feature so I haven’t looked at the code).

Just wondering what thoughts on this behavior are. Sorry for making so many issues, I know you’re trying to lock down API changes soon so I’m getting all of them in 😉

[Mgamerz]

It may take me a bit to get to this, but I’ll try it once I get a bit of time.

[tig]

No stress. This is all for fun and learning anyway so @bdisp and I will happily help as you make progress!