CEGUI (Crazy Eddie's GUI) Forums

Hello!

My application uses collections of items that I've binded to CEGUI items GUI Elements (that inherits from CEGUI::Window), and browser GUI Element for these collections, using the CEGUI::GridLayoutContainer class.

The thing is that my application creates, destroys and handles the browser GUI Elements and the item GUI Elements directly with their pointers.
When I create the CEGUI elements, I always have to give them explicitly a Window Name, which sometime is very painfull, because it has to be unique in the whole CEGUI System (I know that version 0.8 deals with window names that can be reused in different ''branches'' of the widget hierarchy.

I'm working with the 0.7 version because I need a stable version of CEGUI.

So the solution I've used until yet is to create a static 'int' counter in my class that inherit from CEGUI::Window, and give to the constructor of this class the name of the widget, and an autoincremented index.

This seems very heavy!

My question is: Is it possible to create Windows without having to deal with windows name management, and avoid name collisions ?

I answer myself to mysel:

It's very easy to have unique names for windows. Just pass the pointer as a name for the window:
For example, the constructor of my custom class would be:

If you mean you create the custom Windows via the new/delete operators, then you're a very, very naughty boy This said, I'm glad you found a pretty simple way to handle the naming - although if names are not going through CEGUI::WindowManager, I think you could use blank names anyway, though I'm not 100% sure (ironically, that should would work in 0.7.x, but probably would not in 0.8.x).

CE.

Hello Eddy !

Thanx for your answer and for your wonderfull library!

Why is it naughty to create Windows by 'new' ? Is it because it uses a Fabric Pattern, and need to know which type is it when created? (StaticImage, StaticText etc....) ?

Indeed I would like to make it so, but when I tried, nothing appeared on screen.
It would be very usefull to create custom widgets with windows member that are not pointers, and that are destroyed when the widget is destroyed....

In my project (uses CEGUI 0.7.5) we use empty "" names for all of the windows that are created in code (as opposed to xml). We are using the WindowManager to create windows.

CE, it sounds like you are saying that that capability will not be in 0.8. Even if things HAVE to have names, it would be nice to be able to say: "Create a window/widget, I dont care what its name is."

matt wrote:Why is it naughty to create Windows by 'new' ?

There are two main reasons, the first is for management reasons - basically it's somewhat helpful for the system to know what objects were created in order that they can later be cleaned up nicely. The other reason is related to the structure of the provided widgets and the fact that (as you found, I think) if you create a CEGUI::PushButton via the new operator, nothing will be rendered for it - this is because when creating a objects via the WindowManager, usually you are actually creating two objects - one of a CEGUI::Window derived class and another of a CEGUI::WindowRenderer derived class - and then associating these with each other along with a 'WidgetLook' specification (usually that was loaded from looknfeel XML), and together these three items form the 'Window' that you see rendered on the screen.

It should be possible to create Window subclasses that do all of their own rendering; that do not rely on a WindowRenderer or WidgetLook. You would just add this to WindowFactoryManager via the addFactory template (in 0.7.x likely using the TplWindowFactory wrapper). Then you could create instances via WindowManager. If this does not work, and you get some exception about needing a WindowRenderer, then that's a bug which should be reported

KishukuOni wrote:In my project (uses CEGUI 0.7.5) we use empty "" names for all of the windows that are created in code (as opposed to xml). We are using the WindowManager to create windows.

CE, it sounds like you are saying that that capability will not be in 0.8. Even if things HAVE to have names, it would be nice to be able to say: "Create a window/widget, I dont care what its name is."

I will explain the situation in a bit more detail

In 0.7.x when you create a window using the WindowManager and pass the empty string for the name, the window will actually receive a unique name that is generated internally, and this has not changed in 0.8.x.

The change in 0.8.x basically introduces the concept of a name 'path' for windows that are part of a hierarchy. Prior to 0.8.x, the idiom has been that windows are named according to the hierarchy the user creates. So typically you have a root window named "Root" and to this you might add a FrameWindow, and because it's attached to the root, you name it "Root/MyWindow", and if you then decide to add a button to that FrameWindow, typically you name it "Root/MyWindow/SomeButton". Which is all very nice, but in complex scenarios, it becomes a real PITA to keep names unique. In 0.8.x, windows are named more simply: the root would still be "Root", but the FrameWindow should be named simply "MyWindow" and the button simply "SomeButton" (it is possible to create multiple windows with the same name). When you combine these windows, CEGUI 0.8.x automatically deals with the path-like aspect of hierarchical names - so even though the separate windows no longer contain the full 'path' of the name, you can still ask the root window for "Root/MyWindow/SomeButton" and get the right window. The really cool thing is that you can remove the button from "MyWindow" and add it to "MyOtherWindow" and the path to the button changes to "Root/MyOtherWindow/SomeButton".

Anyhow, how does this relate to what I said, and why would empty names not work in 0.8.x? Basically, I said that because matt is creating names via the new operator rather than WindowManager, and I said that he could probably get away with using empty names. When creating windows in this way, if you specify an empty name, the name really would be empty, as opposed to receiving a generated name from WindowManager. This is significant because in 0.7.x you can theoretically add multiple child elements to a window, where those child elements all have the same name (bypassing the WindowManager would allow that to happen). In 0.8.x, because detached windows with the same name are fully supported, and because the path-like behaviour is constructed internally, we must check that each window only has one immediate child with any given name - so adding multiple child elements with the same name would throw an exception.

That's a lot of waffle to basically say: do not worry, when using WindowManager to create windows with blank names, this will continue to work in 0.8

CE.

Thanks for the clarification.

Thank you Eddy for this help!