Modal system

[paddy]

If at all possible, it would be quite usefull to be able to use windows like modal dialog boxes.

Right now, I have to have a function that gets to the point of needing user input, showing a dialog, then having a function trigger when they click the close box.

Something like:

int i = someModalFunction("Pick a Number");

would make it a lot easier.


I am not sure how something like this would be implemented, I searched the forum and saw some code suggested (http://www.cegui.org.uk/modules/newbb/v ... 25&forum=2)

...but I don't know if I can (at least with ogre) use that 'waste loop' because I think ogre needs that thread to finish before it can pick up the event that would exit the loop. I really am not sure.

So, I suppose the idea I have is if there is a ModalFrameWindow that is a subclass of FrameWindow, that has a data member named modalResult of ModalResult class type, and function members called closeModal(),showModal()...the user could wire any button they add to that window to the standard closeModal() function, and wire the other GUI elements to update some sort of data storage of ModalResult.

All modal startup, sleeping/synching/etc, and close down would be handled between that base class's showModal() and closeModal() and let the programmer use it like:

ModalResult modalResult = mywin->showModal();


I really have no idea if that is the right way to do it, its just an idea of a way. I think it would be useful to have that functionality handled within the CEGUI system, instead of at the application level if possible.

But if that method is not practical, has anyone successfully tackled this and if so, can you point me in the right way?

[gcarlton]

It requires a separate thread, which is the sort of implementation that is specific to the app, rather than the gui library itself. You'd have to get some ogre experts to see whether threading is easy or hard using that engine.

There are alternatives, depending on what your application is like. For example, I have a stack of game states, and so a model window is just a new MessageBox state that is pushed on the state stack. When the gui window closes, the state kills itself and pops itself off the stack, with some handywork for its final return value before it dies.

The sort of code you get then is a bit more complex and usually involves a callback for what to do after the window closes.

[CrazyEddie]

There are so many ways to pull this off, and currently how to do it is very implementation specific (as gcarlton points out).

If you need to be able to call a singlr method and not have it return until the window is closed (or whatever), then you're definately going to need to use threads. This is because you still need your app to update things and feed in the inputs etc (it's your app that drives the GUI remember, so if the GUI system were to block, everything else would stop also).

I may at some stage add a 'modal' flag to Window, which would basically ensure that only that window (and it's children) get inputs, though the app would still need to handle entry and exit of that mode; it would not be a single method solution.

CE.

[paddy]

Thats fair, I wasn't sure if the idea I had was flawed or not on a threading level.