Fix modal disable/enable behavior on Win32 #106
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 PR fixes the modal behavior of native file dialogs on Win32. Previously, opening a native file dialog would leave the calling window enabled. This is not how NFD behaves on macOS, though I do not know how it behaves on Linux.
More importantly, this issue exposes folks with immediate-mode GUI libraries like Dear ImGui to crashes on Windows. If you use
WM_SIZING
messages or similar to redraw an immediate mode GUI, but an NFD is open because of a call from the GUI, then a user can break things by resizing the calling window with an NFD still open. Dear ImGui, at least, does not support recursive UI rendering.This fix simply passes the calling window handle to
fileOpenDialog->Show()
, which it gets from GetActiveWindow(). IfGetActiveWindow()
can't get a handle, it returnsNULL
anyways, so this change should not negatively impact existing projects. If anyone prefers to avoid disabling the base window when opening an NFD, then I'd argue that should be an API change, because again, this is the default behavior for NFD on macOS.I tested this with Clang and MSVC on Win32.