[Solved] Resizable child windows with absolute margins

[Garthy]

Greetings.

I was wondering if there was any way, either programatically or via layout files, to specify that a child window should use the remaining space of a parent window, less absolute margins on the sides. More precisely:

I have a resizable FrameWindow that has certain widgets of fixed absolute position and size at the top (let's say 200 pixels for reasons of simplicity), and certain widgets at the bottom (let's say 50 pixels). I would like to place a ScrollablePane in the remainder of the area. If the height of the window is 'h', the available space should be 'h-250'. I would like this to be the size of the ScrollablePane.

Using ASCII art:

Code: Select all

+------------------+ -+    ---+
|Fixed-size widgets|  |       |
|                  | 200      |
+------------------+ -+-+     |
|                  |    |      h
|                  |    |     |
|  ScrollablePane  | (h-250)  |
|                  |    |     |
|                  |    |     |
|                  |    |     |
+------------------+ -+-+     |
|Fixed-size widgets| 50       |
+------------------+ -+    ---+


Now, getting the initial absolute position of the ScrollablePane isn't hard (it's 200 pixels), but I do not know how to specify the size. If I used an absolute size, it would not adjust as the parent FrameWindow is resized. If I use a relative one, it would, but the distance from the bottom of the window would not remain constant at 50 pixels, it would change.

Another similar but simpler problem is asking how to specify a widget that maintains an absolute gap of 4 pixels from the top and bottom of the window, which survives resizing. Again, the start position is easy, but the size is hard. This ends up being a second part of the above problem- if the top and bottom regions have a fixed absolute padding, you might want that same padding on the left and right too.

The workaround is to specify everything using relative coordinates, which doesn't work so well if part of the interface needs to remain fixed-size. Alternatively, you can always disable resizing and place everything using absolute coordinates.

Does anybody know how to solve this one?

[ShadowTiger]

There may be some way to do this using a mix of relative and absolute values... but I don't know how.

you can probably add padding in the looknfeel, but after failing to get some basic stuff working I can't say for sure.

I do know that you can subscribe to the resize function of the frame window and then resize the scrollable pane and move all the fixed widgets accordingly. This may be your best option.

example:

Code: Select all

FrameWindow->subscribeEvent(CEGUI::FrameWindow::EventSized, Event::Subscriber(&(yourFunctionHere), this));

Finally, what I would pose as an option is not to use built-in cegui widgets.

I have made my own scrollable pane and my own pull down menus, and its very easy. I assume that I am saving on loading time as well.

However, if you do not want to do this, then my previous suggestions or another forum user might help you.

[Garthy]

Cheers, thankyou for the suggestions.

I do know that you can subscribe to the resize function of the frame window and then resize the scrollable pane and move all the fixed widgets accordingly. This may be your best option.

I haven't looked into this but I was also wondering if this might be the approach to take. If I used user properties I could just develop a simple layout system with the parameters I need, and activate it on resize and initially. I'm guessing you've done something like this? Assuming that I can muddle about with figuring out the placements, is it simply just a matter of calling setPosition and setSize with absolute dimensions for all the children during the resize callback/subscriber? Does other things (such as schemes and the look 'n feel code) interfere with this?

I have made my own scrollable pane and my own pull down menus, and its very easy.

That's quite interesting- I know that this sort of thing is not always the easiest thing to do, depending on the toolkit.

I might hold on a little bit in case there are any further ideas. It would be odd if there was presently no way of specifying "rest of the window" in some way- it's a pretty common thing with windowing toolkits. I'd just assumed I hadn't figured out the right way to do it yet. :}

[Kulik]

Several ways to do this, I will describe the pure UDim approach

Top has absolute height 200, bottom has absolute height 50, so the centrepiece has to have height "parent height - 250px" = UDim(1.0f, -250.0f) and has to be in position UDim(0.0f, 200.0f). The top piece has position UDim(0, 0), the bottom piece has position UDim(1.0f, -50.0f)

I am planning to make a video tutorial about this, it's a fairly simple and powerful system but most people seem to struggle with it (probably because relative can mean 2 different things in the context :-/)

[Garthy]

No way! It's that easy?

I've just started experimenting with it and I think that is going to solve my problem entirely.

I've summarised my understanding from your post for the x-coordinate here:

{a, b} : a * width + b, b can be positive or negative
{0.0, x} : x pixels from left
{1.0, -x} : x pixels from right (100% of width, minus x)
{x, 0.0} : x * 100% of the width

with similar use for the size, and used similarly for the y-coordinate.

So, with borders of l, r, u, d, in general you would use:

Position: {0.0, l} x {0.0, u}
Size: {1.0, -l-r} x {1.0, -u-d}

... and I'm guessing you can do some clever tricks with values between 0 and 1 for the relative position when combined with absolute offsets as well.

I think I understand the decision behind unified coordinates now. Anyway, off to play with some dialogs to confirm it all works.

[Garthy]

... and it works! The problem I described is entirely solved by using UDims in the way you describe. Thankyou Kulik.