The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I'm trying to prompt the user for a file, using GetOpenFileName, and I've run into a number of problems when my app is running in fullscreen mode.

I'd like the system to behave in one of the following ways:
Desired: The open file dialog displays on top of the fullscreen app.
Fallback: The fullscreen app minimizes itself and displays the dialog. When the dialog is closed, the app restores itself.

Existing behavior:
When the dialog is created, the app minimizes, but the dialog does not gain focus. Whichever explorer window was in focus before launching the app gets focus. This can cause the open file dialog to appear behind other windows obscuring it from the user. Also, when the dialog is closed, either by selecting a file to open or canceling, the app stays minimized and does not restore itself. If the dialog was parented, the app regains focus but does not restore, if the dialog was not parented the app doesn't regain focus.

So there seem to be a number of problems.

1) When the dialog window is created, it does not acquire focus.*
2) When the dialog is closed, the app doesn't restore.
3) (optional) Even if the dialog is parented to the app, it minimizes the app.

*This also happens in windowed mode if I am launching/running the app in the Remote Debugger. If the app is launched by itself on the client machine it only appears to happen in fullscreen mode.

I've got possible fixes for 2 and 3, which I'll post below so not to clutter this post, but I don't know how to fix 1, which is the main problem. Any ideas how to fix this one? If there is a better way to handle dialogs (or let the user browse for a file), I'm open to hearing that, too.

I'm running on Windows XP SP3 (though Vista exhibits this behavior as well).
This is using SDL version 1.2.13, though from looking at the code from later versions (including 1.3) it seems 2 & 3 still exist there. I haven't been able to evaluate 1 on any later versions.

Fix for 2) When the dialog is closed, the app doesn't restore:

In SDL-1.2.13/src/video/wincommon/SDL_sysevents.c
Function WinMessage
case WM_ACTIVATE

existing code:


When the dialog is created, the app minimizes itself. Once the dialog is closed, the app receives a WM_ACTIVATE message while minimized. Since active is only set to true if minimized is false, the app doesn't call SDL_RestoreGameMode(). This can be fixed by changing the line assigning active to the following:



Does this seem reasonable? What is the reasoning for not restoring a minimized app on WM_ACTIVATE? Maybe I'm missing something.

For 3) Even if the dialog is parented to the app, it minimizes the app, the following fix works (:

In SDL-1.2.13/src/video/wincommon/SDL_sysevents.c
Function WinMessage
case WM_ACTIVATE



This seems to work, but I don't know if it's supported or undefined behavior. The problem is that it still has the focus bug on some versions of Windows so the dialog is sometimes created underneath the fullscreen app, which is obviously bad. Seems to work on XP SP3 but fails on Vista.

Also, I don't know if it helps but these are the Windows messages my app receives during the dialog creation/closing process, along with some of the SDL calls that handle it (with stock v1.2.13 code). Note especially the WinMessage WM_ACTIVATE re-entry, caused by the ShowWindow call in RestoreDesktopMode to minimize the app.

Ah... That is probably the issue. The first WM_ACTIVATE has the proper dialog hwnd in its lParam, but the ShowWindow(SDL_Window, SW_MINIMIZE) call to minimize the app causes another WM_ACTIVATE with a NULL hwnd lParam, and it might be messing up the focus somehow.

I still don't know why the dialog's focus would be lost if the app isn't minimized, though. I've only seen that behavior on Vista, not XP, so it's not as easy for me to test.

App hwnd = 0x580112
Dialog hwnd = 0x6600F6

alk,

Did you ever get this to go as planned without any hitches? It seems like there is a little more troubleshooting that never took place in the thread, I'd love to hear more about it if you got it fixed it could be a really great learning tool. I would gladly volunteer my time, but because of the way my system focuses on my home business I feel it is in my best interest to protect my bcm software at this time rather than start digging back in to my troubleshooting days.

Never got it to work the way I wanted, no. I had to ship something, so I just had the open file dialog minimize the fullscreen app, as ugly as that is. If I didn't do that, then on other versions of Windows (Vista?) the dialog wouldn't get focus and would pop up behind the fullscreen app, making it look like the app had hung, which was unacceptable.

I probably spent more time diagnosing this problem than it would have taken to write a custom, in-app file browser, instead of trying to use the Windows API. Oh well. If you want to investigate it any further, be my guest. Let me know if you figure anything out.

It seems like the fix for #2 should definitely be adopted into the SDL, as it is a legitimate bug. I'm not sure what the process is for that, though.

Could you take the time and file a bug at http://bugzilla.libsdl.org/
Please include as much detail as possible: SDL version, repro code, target platform, compiler settings, screenshots, etc.
--Andreas