CEGUI (Crazy Eddie's GUI) Forums

Oops, didn't log in.

The window manager is already there, but is the idle thread thing really necessary or is there another method of destroying windows?

Yeah this is a bit of a pain. The crash is due the the object being deleted while the event system is still iterating over the subscribed listeners.

Presently, maintaining a window "dead list" is about the only way to go. I've given this a little thought and I might integrate this approach into the CEGUI::WindowManager itself, though one drawback would be that the client code would then lose control over when the dead-list actually gets cleaned.

CE.

I ended up writing a Window Manager (just a simple list) and custom window classes for each window I make in the app. Then when a window is to be deleted, it hides, deactivates, and sets my custom window classes isDestroyable flag to true, then the Window Manager can clean it up during idle time.

I have the same window destroying problem and I wanted to know how to do something during idle time ? How can I know that it's idle time ?

Idle time is just time when you're not doing anything else. Only you can know when this might be for your particular project.

CE.

Yeah this is a bit of a pain. The crash is due the the object being deleted while the event system is still iterating over the subscribed listeners.

Presently, maintaining a window "dead list" is about the only way to go. I've given this a little thought and I might integrate this approach into the CEGUI::WindowManager itself, though one drawback would be that the client code would then lose control over when the dead-list actually gets cleaned.
CE.

Hi, CE - Welcome back! I hope your holiday was great!

In coding up my application I made a few small changes to CEGUI that enables me to close and destroy windows on a button click. The changes are in three places: CEGUISystem.cpp, CEGUIEvent.cpp, and CEGUIPushButton.cpp. The changes all revolve around checking to see if the event has been handled. For instance, in System.cpp::injectMouseButtonUp:


The other changes are quite similiar. This way, when a button is clicked to close a window the handled flag is set and halts the iteration over the subscribed listeners. Thus, the window can be easily deleted inside a message handler and the stack unravels cleanly.

I'm using the heck out of it in my code. Would you like me to submit the changes to the project tracker?

cheers,
Chris

Hi,

Thanks, it was very nice to get away from CEGUI for a while

Please feel free to submit a patch to the tracker. I can't promise I'll use such an approach over the "dead list" / deferred destruction idea, but at least there would be something for people to use while I sort things out

I suspect that your approach involves stopping calls to subscribed listeners when one of them returns true; I currently think this has potential to cause major issues since the event system is supposed to guarantee that all listeners get called (obviously in the case of a window being destroyed it is not important, though in other, possible unknown, cases it could be important that all other listeners get called even though a previously called listener has already indicated the event as handled).

Anyway, as I say, submit the changes because until a final decision is made there's probably many people who would benefit from a functioning system that allows window destruction to be triggered from events.

CE.