re: treading… honestly I wouldn’t want it to be required to ONLY be on the main thread (For unparented). As that makes this a little more icky for the consumer to have to push assert errors to other threads.
In porting of games developers use dialogs commonly in their assert handling. Mostly normal debug annoyance ones in debug mode. And the fatal ones kept in release mode. (e.g. followed by an exit, or term). And they will throw them up from any old thread…
FLTK (which I currently use for dialogs) only has the requirement that only one “common dialog” can be open at a time. and additional requests are ignored. (read: http://fltk.org/doc-1.3/group__group__comdlg.html )
Now, my normal usage of that is a simple helper routine that locks FLTK’s GUI access (Fl:Lock), displays the dialog, and unlocks after the user dismisses the dialog. For example my ConfirmDialog wrapper looks something like this (and is cross platform too). Now obviously these don’t support “parents” other than other FLTK windows (which for SDL isn’t the case). and I also do some NASTINESS with popping out of fullscreen to present the dialog.
Fl::lock()
fl_message_title(title);
long ret = fl_choice("%s", “Yes”, “No”, 0, message);
Fl::wait(0);
Fl::unlock();
return ret == 0;
I actually added a key binding (Ctrl-1) to common.c so you can try showing a message box in any SDL test app. It does use the existing window as a parent, and will be a good fullscreen test once that’s supported.
It’s probably worth adding another test that prompts before SDL is initialized to make sure that works correctly. I’ll adapt yours to do that as well.
I hadn’t thought through the multi-threaded implications of this. I think for sanity at least for now the dialog should always be popped on the thread that created the parent window (if any) or the main thread if it’s unparented. It is intended to be modal and block that thread until the user provides input. I’ll add this to the documentation.
Thanks! Good luck on the fullscreen fight, and let me know if you make any progress on that front. 
I noticed the inclusion of the new MessageBox API today… And I thought “Nice!”. Currently I’ve been including FLTK to provide dialog box services to game ports, and while it does the job quite well, it does add a lot of hard dependencies on X.
Anyways I’ve submitted a patch as Bug #1630 ( http://bugzilla.libsdl.org/show_bug.cgi?id=1630 ) that adds a simple test to show of the SimpleMessageBox and a Custom MessageBox. . It currently does not show off the color scheme, nor making another window a “parent”.
A few questions about the implementation (or intended implementation).
Does it block access to ALL SDL windows or only the “parent window” when specified?. Can more than one be displayed (e.g. multiple threads), should there/is there any blocking?
Overall I’m impressed and this definitely simplifies things while I port games. (/me returns back to testing/fighting with fullscreen support now)
–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296
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
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296On Oct 30, 2012, at 13:04 , Sam Lantinga wrote:
On Sat, Oct 27, 2012 at 11:44 AM, Edward Rudd <@Edward_Rudd> wrote:
Isn’t this how MessageBox