Dialogs do not return focus to parent window on Windows and GM LTS

[Grix]

A user reported that after a recent update in my software, in which I updated the DialogModule version, the main window loses focus after a dialog opens, and the focus stays lost after the dialog is closed. This causes problems such as the user having to manually click on the main window again to return the focus so that keyboard keys work again.

I believe the change was introduced while fixing a previous issue in DialogModule, the code history of which has been lost to time due to the git repo being deleted iirc. But the change was related to dialog boxes being centered on the screen to avoid appearing outside the screen boundary due to display scaling settings. When using a dll from before this fix, the focusing works fine.

However, the issue seems to be restricted to certain scenarios. It happens for me on Windows when using GameMaker LTS 2022. It happens even if I use widget_set_owner(window_handle()); or widget_set_owner(string(int64(window_handle()))); . In fact the former seems to occasionally crash the entire program.

But when I use the modern GM version and the example project from this git repo, then by default the focus problem still happens but if I add widget_set_owner(window_handle()); then the problem is resolved as expected.

So there seems to be something different about how modern GM and 2022 LTS GM handles the widget_set_owner function and focus?

Unfortunately I don't think I am ready to try to port my whole project to a modern GM version yet. I tried once and nothing worked, it would be a huge endeavor.

[samuelvenable]

widget_set_owner(string(int64(window_handle()))); is the proper and intended way to use that function. it takes an unsigned long long (which is not the same thing as an int64_t but close enough precision between the two for this use case) casted from a window pointer, and wrapped in a string. Using the pointer directly with widget_set_owner(window_handle()); causes it to crash because that is incorrect use of the function.

Is this a Windows-only issue? Or is it also present on macOS and Linux? On Windows, this should be very easy to correct, and is just a matter of calling AllowSetForegroundWindow(), SetForegroundWindow(), SetActiveWindow() and/or SetFocus(). I'll see whether any combination of those function calls corrects the issue, and if not, it may be due to the fact I am forcing the parent window to not get disabled when a dialog exists, which is correctable by reverting that behavior and allowing the dialog to disable its parent window like it did previously. Disabling the parent window imo is annoying and should be avoided, at least when possible, because it prevents the window manager from allowing the user to move the window by its title bar, minimize it, etc.

[Grix]

It is on Windows, I have not tested on mac and linux because I still use an old version of the library on those platforms, there haven't been a need to update since everything works fine.
Thanks for looking into it. It's no rush though. I know I said that I'm not ready to port my project to the latest GM version but I'm looking into doing it anyway since it would have to be done at some point, so the issue may fix itself eventually once I've finished with that.

[samuelvenable]

@Grix I've updated the extension and the owner/parent window should now regain focus when a given dialog exits. Make sure you call widget_set_owner(string(int64(window_handle()))); before attempting to create any dialogs for these changes to take effect.

Unfortunately, this fix I made introduced a new issue: now that the parent window regains focus properly, when certain dialogs open they do not have window focus when they are created; this is more of an aesthetic-related issue as the dialogs behave the exact same as before, except when they don't have focus the title bar text is greyed out. I'm not sure what to do about this right now.

The keyboard keys and everything else seem to still work even without the dialogs having focus, so it's not as big an issue.