Redrawing SDL window underneath a MS Windows dialog box?

If I show a MS Windows open/save file dialog (i.e. using GetOpenFileName or SHBrowseForFolder) and drag that dialog box around in front of my SDL window, the SDL window is not redrawn as the dialog is dragged around, leaving bits and pieces of the dialog behind as it is dragged.

Is there a way to fix this? I tried adding response to the SDL_WINDOWEVENT_EXPOSED event, but that didn’t do the trick.

The windows redraws itself as soon as the dialog is closed.

-Vern

No one here uses a standard Windows Open File dialog box with their SDL 1.3 / OpenGL program?

The problem here is that Windows controls the event loop while the dialog
is up and SDL doesn’t get a chance to run.

I’ve heard that you can solve this with multi-threaded rendering, but I
haven’t seen any solid example of this.On Mon, Nov 14, 2011 at 6:51 PM, VernJensen wrote:

**
If I show a MS Windows open/save file dialog (i.e. using GetOpenFileName
or SHBrowseForFolder) and drag that dialog box around in front of my SDL
window, the SDL window is not redrawn as the dialog is dragged around,
leaving bits and pieces of the dialog behind as it is dragged.

Is there a way to fix this? I tried adding response to the
SDL_WINDOWEVENT_EXPOSED event, but that didn’t do the trick.

The windows redraws itself as soon as the dialog is closed.

-Vern


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sam’s right: when you call MessageBox() or GetOpenFileName(), the function
doesn’t return until you close it. In the mean time, the code to check the
Win32 message queue (in SDL) never runs because you never return to
SDL_PollEvent() or whatever. I’d imagine that you get the expose event when
the box is closed. The simplest solution would be to create a new thread to
do the dialog box, and use an SDL_mutex to protect a common variable. In
Win32 programming, each thread has its own message queue, so you wouldn’t
interfere with SDL messages. A more complex example that doesn’t waste CPU
cycles would be using a condvar, but this isn’t meant to be a great example.

Your code would look like:

volatile bool g_done;
char g_filename[MAX_PATH];
SDL_mutex* mutex;

get_file() {
g_done = false;
g_filename[0] = ‘\0’;

SDL_CreateThread( … );

return
}

main() {

mutex = SDL_CreateMutex();

get_file();

bool done = false;
do
{
SDL_LockMutex(mutex);
if(g_done)
done = true;
SDL_UnlockMutex(mutex);

SDL_PollEvent( … );

//render code here
} while(!done);

}

dialog_thread() {

GetOpenFileName();

SDL_LockMutex(mutex);
g_done = true;
g_filename = file;
SDL_UnlockMutex(mutex);
}—

Patrick

On Wed, Dec 28, 2011 at 4:49 AM, Sam Lantinga wrote:

The problem here is that Windows controls the event loop while the dialog
is up and SDL doesn’t get a chance to run.

I’ve heard that you can solve this with multi-threaded rendering, but I
haven’t seen any solid example of this.

On Mon, Nov 14, 2011 at 6:51 PM, VernJensen wrote:

**
If I show a MS Windows open/save file dialog (i.e. using GetOpenFileName
or SHBrowseForFolder) and drag that dialog box around in front of my SDL
window, the SDL window is not redrawn as the dialog is dragged around,
leaving bits and pieces of the dialog behind as it is dragged.

Is there a way to fix this? I tried adding response to the
SDL_WINDOWEVENT_EXPOSED event, but that didn’t do the trick.

The windows redraws itself as soon as the dialog is closed.

-Vern


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org