getChildrenArea doesn't work

[GoogleCodeExporter]

What steps will reproduce the problem?

1. calling BaseContainer::getChildrenArea()

What is the expected behaviour? What happens instead?

A Rectangle of the Surface occupied by the children should returned. But
the rectangle parameters are all 0.

What version of the product are you using? On what operating system? Which
back-end (SDL/Allegro/OpenGL/other)?

Debian/etch i386
SDL 1.2.11
Guichan 0.8.1

Please provide any additional information below.

The Code is attached. The function call ist at line 127.

Original issue reported on code.google.com by ma.kalbf...@googlemail.com on 15 Sep 2008 at 7:01

Attachments:

• test.c
• test

[GoogleCodeExporter]

I looked at the source code, and saw, that this function returns a Rectangle 
with the
width and height of the container, but not the Position. So this function is a 
partly
working version of getDimension and therefore not described one. 

Original comment by ma.kalbf...@googlemail.com on 15 Sep 2008 at 7:51

[GoogleCodeExporter]

It does what it is suppose to do. BasicContainer::getChildrenArea should return 
an
area relative to the BasicContainer, hence a rectangle with position (0,0) and 
height
and with of the BasicContainer is the whole BasicContainer.

If the rectangles parameters are all zero then your container has zero size.

I looked at your code and this line:

this->setDimension( this->getChildrenArea () );

doesn't do anything as getChildrenArea relies on getDimension, so you are 
basically
setting the dimension to zero size. BasicContainer::getChildrenArea is NOT the 
same
thing as computing the area of all widgets inside the container. Why? Because 
the
method is used when drawing children of a BasicContainer. Take the ScrollArea 
as an
example, it's children area is the area where you can view the ScrollArea's 
content
and that area is computed and set by the ScrollArea. BasicContainer retrieves 
the
area by calling getChildrenArea which ScrollArea overloads. Perhaps the docs 
should
be enhanced.

Original comment by olof.nae...@gmail.com on 15 Sep 2008 at 9:39

• Changed state: Invalid