Hello!
Here is a basic example. Create a User Widget, set it as Screen Size / Desired and as root have a Horizontal Box. As children add a Text and a Text Box, and set both of them size 1 fill.
As you can see the Text is over the space of the Text Box and not just inside it’s own space. Normally the Text Box should have the same size as the text as in this example that one is the widest of the two, with the size set as desired for the widget, meaning it isn’t constrained by the size as it can get as wide as it needs to.
The problem gets worst when you are using that widget Z1 inside another one. As an example duplicate Z1 (I named it Z2), and leave it the same, just edit the text value and add something else (I set it to “This is yet another test”).
Same problem as before with the spacing, but let’s move on, and add both Z1 and Z2 inside another widget (I named it Z3) using the structure:
As root of Z3 have a Canvas Panel, then as a child of that canvas add a Vertical Box(I used 1920 x 110 size X / Y), then as a child of this, add a Vertical Box, but this time set size 1 fill with Horizontal Alignment / Center and Vertical Alignment / Fill Vertically. Then as a child of the last VB add Z1 and Z2 as fill 1 (I added a padding of 10 to bottom to Z1 to have a little gap)
In theory this should make Z1 and Z2 to have the same size, and the text inside them should not overlap with the text box. But that is not the case. It should basically have the same effect as if you used Uniform Grid Panel and have the text and text box elements set inside it.
Here as you can see it knows that the widest cell is “This is yet another test” Text, and set that to the rest.
What I described are just some basic examples, in my case I have more complex widgets, but the root problem is the same, that it doesn’t respect the sizes, and it makes elements overlap one another when they clearly are not restrained by the space they are added into.
Like in the above example, neither Z1 nor Z2 have the width larger then 1920 of the VB they are added into to cause the overlap.
And so the big question, is this a bug or a limitation of the engine when it comes to the sizes of the elements?