   Modal Dialog boxes in a GUI
  I am writing a GUI for OpenGL in C++, which is going fine so far but I can't work out how to implement a modal dialog box.  By a modal dialog I mean one that when created has to be closed before you can use any of the GUI again, e.g. you may have code like this:int result = CreateDialog( );Where result would store the ID of the button used to close the dialog box (or some such thing).Windows handles this by having a competely seperate message loop for modal dialog boxes so when you create a modal dialog boxes it jumps out of the current running processes code and runs the dialog boxes message loop.  When this termiates (e.g. the dialog box is closed) it then jumps back to the process that created the dialog box and returns an appropiate value.I was wondering how I could do this in my GUI.  It is intended to be used in a game so somewhere there'd be a game loop that at some point calls functions like GUIUpdate( ) and GUIDraw( ).  So creating a whole new loop inside my CreateDialog function isn't something I want to do.  Ideally I'd like to be able to jump from the CreateDialog function back to the main game loop and then when the dialog box is finished, jump back to the CreateDialog function and return the appropiate value.  Can anyone think of I way I could do this?   
  Maybe not the main loop but some other loop? If there is a CreateDialog() call inside the main loop, you might get an endless recursive.What about function pointers?   ;Quote:Maybe not the main loop but some other loop? If there is a CreateDialog() call inside the main loop, you might get an endless recursive.Well when a modal dialog is up on the screen the rest of the GUI is effectively disabled until the modal dialogue is closed, thus CreateDialog should either not be called or would be a no-op.And I don't really see how function pointers can solve this situation.  Effectively what I'm asking is if there's a way to jump out of a function half way through, without returning to the caller and then jumping back to the exact same place in the function.  I guess I could use threads to do it, but I'd prefer not, though I don't see any other way I could do it ATM.   ;Quote:Original post by MonderAnd I don't really see how function pointers can solve this situation.  Effectively what I'm asking is if there's a way to jump out of a function half way through, without returning to the caller and then jumping back to the exact same place in the function.  I guess I could use threads to do it, but I'd prefer not, though I don't see any other way I could do it ATM.typedef int (*FUNCPTR) (int, int);int CreateDialog( FUNCPTR ptr ){   ...   int result = (*ptr)( arg1, arg2 );   ...   return blah;}Unless I misunderstood the question.   ;  you could split the main loop into separate functions, so that you can call some of those functions from you dialog loop.   ;  Hellsp4wn: I'm trying to avoid creating a version of the main loop in the CreateDialog version, especially as the GUI is not going to be the only thing in the main loop.alnite: I guess that could work, but I don't really like the recursive calling of the main loop.I guess what I really need is a way to implement co-routines in C++.  I'm taking a look on google now and I've found a couple of things.   ;  Well, if you've split your update functions from your render functions, or whatever else you might want, then I see nothing wrong in creating a "version of the main loop".After all, it's a common solution to these things...Also, if you split the main loop into clever functions, there would be no problem expanding it later...   ;  Doing a quick brainstorm here:In my GUI system, all elements use children and such to store and if wanted container objects to position them. However, there will be a root node which would represent the entire screen. If the user presses a key or moves the mouse, this is passed to the root node, which recurses it down into the tree. Rendering is handled similarly.This creates the possibility of inserting a new object (the modal dialog) immediately below the root (thereby moving all of root's children beneath the modal dialog node). Then if the root receives a mouse message or a keystroke, the modal dialog can intercept it, and choose NOT TO propagate it into the tree. Once the modal dialog is handled to its satisfaction (clicking cancel or whatever) it can remove itself, and boost all it's children up to the root again, thereby creating the menu/screen as it was and also automatically reconnecting the functionality.   ;Quote:Well, if you've split your update functions from your render functions, or whatever else you might want, then I see nothing wrong in creating a "version of the main loop".After all, it's a common solution to these things...The problem is the GUI library doesn not know what's in the main loop, all it knows it that at some point GUIUpdate( ) will be called and at another point GUIDraw( ) will be called.If I used alnite's solution the the whole main loop would have to reentrant, which could prove to be a problem.   ;  rick_appleton: That's how my GUI system works as well.  That is something like how I was planning to implement a modal dialog box but the problem still remains of how I can call CreateDialog, jump back to the main loop and then when the dialog is closed jump back into CreateDialog and return to whatever called it.Looking into it, it looks like I'll either have to forget about having modal dialog boxes (which is no big deal) or implement it using fibres.   