For help with anything that CEGUI doesn't offer straight out-of-the-box, e.g.:- Implementation of new features, such as new Core classes, widgets, WindowRenderers, etc. ...- Modification of any existing features for specific purposes- Integration of CEGUI in new engines or frameworks and writing of new plugins (Renderer, Parser, ...) or modules

EDIT: It's a bit off topic but: Is there a way to calculate Custom Properties (PropertyDefinitions) in a looknfeel file? Or can I define a named area and refer to it in ImageSections? I just want to reduce code duplication.

Last edited by BrightBit on Mon Jun 11, 2012 10:28, edited 1 time in total.

BrightBit wrote:I created a custom GroupBox that has some extra AutoWindows (in addition to "__auto_contentpane__"). Everything works fine. However, during its cleanup these additional windows aren't removed.

Agh! Thanks for this. I've not looked at it yet (aside from your post), but can pretty much confirm this as a bug in GroupBox and likely other widgets that use a similar approach. I will fix this ASAP

BrightBit wrote:It's a bit off topic but: Is there a way to calculate Custom Properties (PropertyDefinitions) in a looknfeel file? Or can I define a named area and refer to it in ImageSections? I just want to reduce code duplication.

There's no way to do calculations in a property definition. In the development code (1.0) we have enhanced the system to reduce repetition and be even more flexible - there you can use a NamedArea or a Property that describes an area as the area for any component (Image, Text, Frame and Child), in addition it's also possible to have a WidgetLook inherit from another WidgetLook. Unfortunately these new abilities are not available in the v0-7 branch code.

UnknownObjectException in file c:\...\ceguipropertyset.cpp(109) : There is no Property named 'BarWidth' available in the set.UnknownObjectException in file c:\...\ceguipropertyset.cpp(109) : There is no Property named 'BarWidth' available in the set.UnknownObjectException in file c:\...\ceguiwindowmanager.cpp(256) : WindowManager::getWindow - A Window object with the name 'Belt__auto_contentpane__' does not exist within the systemUnknownObjectException in file c:\...\ceguiwindowmanager.cpp(256) : WindowManager::getWindow - A Window object with the name 'BeltHealth' does not exist within the systemUnknownObjectException in file c:\...\ceguiwindowmanager.cpp(256) : WindowManager::getWindow - A Window object with the name 'BeltStamina' does not exist within the systemUnknownObjectException in file c:\...\ceguiwindowmanager.cpp(256) : WindowManager::getWindow - A Window object with the name 'Belt__auto_contentpane__' does not exist within the system

I also was able to reproduce this with the default TaharezLook.looknfeel:

Both of these issues should now be fixed in v0-7 branch, I will merge back to default later today.

As far as I could tell, the hang when cleaning up was local to GroupBox and was not duplicated in other widgets that also make use of content panes, though of course let me know if something comes up that I missed

The cleanup seems to work and the exceptions due to the "layoutOnWrite" attribute are gone, too. However, the order in which I define the AutoWindows in the looknfeel file seems to be important now. Is this the intention?

For my custom GroupBox I created two AutoWindow ProgressBars that should not be contained in the content pane (instead they are right next to it). If I define the ProgressBars first, they will be invisible (causing no errors, just invisible). If I define them after the content pane, they will be visible but they will also be contained in the content pane.

Ok, the issue with ordering is likely related to the names you are giving the widgets. In v0-7, the name suffix needs to contain "__auto_" to be flagged as an auto window within the rest of the system, so setting the names to, for example: "__auto_progress1__" and "__auto_progress2__" or some such thing, should resolve that issue.

Now I've said that, I'm going to tell you that you can opt not to use the current GroupBox, and instead use a new technique instead. Basically, the existing GroupBox class is not really needed, and so we are deprecating it in the development code. What you can do instead - and this works in v0-7 too - is create something that behaves the same way via XML alone (but hopefully without all the issues). Effectively this means taking the current <Child> definition for __auto_contentpane__ and turning it into a <NamedArea> where the area is named "inner_rect". For your other auto windows, you should then set the property "NonClient" to "True" to ensure they appear outside the content area. In the scheme, simply update the GroupBox mappings to use the targetType of "DefaultWindow" instead of "CEGUI/GroupBox" and of course remove any casts or whatever you may have in your code.

The NamedArea technique did work except for the fact that this area isn't updated if I change properties that are flaged with redrawOnWrite or layoutOnWrite (or both). Here's a small video to illustrate what I mean:

On the top left corner you should see a tiny rectangle (actually this is a button). It doesn't move even if I change the layout (illustrated by the blending in and blending out of the progressbars). The video was done quick and dirty, so ignore the low qualitiy, please.

I just wanted to say that I've recreated this issue, and am looking at possible solutions. I may not get a fix in for a couple of days or maybe more, as I need to ensure the fix is the best it can be. So far I have found that there are many solutions that are either only partial solutions or are completely inelegant - addressing symptoms rather than the root cause of the issue.

I have made a fix for the issue in your video. The slightly bad news is that I could not make the fix in a way that allowed me to commit it to the v0-7 stable branch. But rather than just make the fix in our unstable development code, I created a new v0-7-incompatible-fixes branch that now contains this fix. While the name looks a little scary, for the most part you should be fine with just a recompile of CEGUI and then your own code - the current single exception to that is if you have custom Window classes that have overridden the Window::performChildWindowLayout function, if you do, you need to update the signature of those to take two bools.