Allow multiple file selection in ui_choose_file #559
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is one of two PRs (The other in haxe for ui.hx) to add support for multiple selection in hl.UI.chooseFile. The haxe side PR can be found here: HaxeFoundation/haxe#10788
Both do weird things for dumb windows API reasons, so I'll explain my sins in advance. Documentation for this API can be found here: https://docs.microsoft.com/en-us/windows/win32/api/commdlg/ns-commdlg-openfilenamea (We use the widechar version, but otherwise the call pattern is identical).
To enable multi select, we really only need to set a flag. Since we just pass a simple
Dynamic
across the fence for this, I just key off a new field and set the related flag. Note we also have to setOFN_EXPLORER
else you get the win 3.x era version of this dialogue... which is magical in its own right.The elephant in the room though is the larger buffer, and the fact that we return the entire thing. The buffer size increase is because this API doesn't really have any mechanism for letting you ask for how many bytes you need; hence we should always oversize. And the size chosen is simply due to that being the largest buffer you can even send this API. We'll need to use a newer API if we want anything more sophisticated.
The reason we pass the whole buffer, instead of the old behavior of just copying the length, is because the return format is null terminated. So
wcslen
will only ever return the path. The haxe commit has the untangling code for converting this data into haxe strings. This code isn't performance critical, so the extra copy shouldn't be a huge deal, andString.fromUCS2
doesn't rely on buffer size.