The buttons are overlaying the header. Ideally they would be just below it like such…
heres the structure of the GUI
halp
Hiya Spankied, good to see you again.
https://www.babylonjs-playground.com/#NNL6FB#2
(sorry for messing-up your alpha settings)
Um… I moved the header OUT OF the stackPanel. Now menu has two children, the header (and its text), and a stackPanel. Then I set verticalAlignment properties on both (not panelVerticalAlignment). Header gets v-aligned to top, the stackpanel gets v-aligned to bottom.
Problem: Line 49 - adaptHeightToChildren: true - I cannot get this to work properly. Every time I activate it, it sets the menu height == stackPanel height… but that blocks (clips?) the header.
So, for now, you will need to adjust line 41 menu height… by hand… to make it look good. Perhaps we can determine WHY line 49 - adaptHeightToChildren is failing.
Lines 119-122… I was playing with .isDirty and .markAsDirty(). With GUI stuff… sometimes things need to render to screen FIRST… and THEN automatic sizers (like adaptHeightToChildren) can start working. By putting my code into an onSceneReady observer, I was hoping to wait until GUI is positioned, measured, squared-up, ready-to-go, and THEN try someContainer.markAsDirty() or .isDirty = true.
uInterface._rootContainer.children[0] IS “menu”, I think.
Doing that kind of onReady stuff… MIGHT make .adaptHeightToChildren start working properly (taking BOTH stackPanel and header into consids, instead-of ONLY taking stackPanel height into consideration, as it appears to be doing). All my isDirty and .markAsDirty tests… failed… so far. You can remove those lines, or continue experiments in there.
I removed a few heights and widths and paddings… no problem. I like to let stackPanel cells (and containers - I removed sizes from header textBlock) determine the widths/heights of its children… automatically (when possible, but mostly widths-only, for stackPanels). I try to avoid forcing child sizes, but sometimes, we need to. I’m far from a pro… at this GUI stuff. Maybe grid control is better than stackpanel?
Ok, menu looks ok, but we have a potential BJS GUI bug in adaptHeightToChildren. It seems to NOT consider its first child… the header… into height auto-sizing. Could be broken, could be Wingnut mistake.
Interesting area: Babylon.js/container.ts at master · BabylonJS/Babylon.js · GitHub Here it appears that MAYBE… all children controls of menu… must have a height set in PIXELS… before adaptHeightToChildren will do anything. I don’t know if we have all our menu children heights… set with pixels. Maybe some height is still using %percentage%… but, it seems not true. hmm. Clipping seems involved, too (clipping settings determine whether container-overflowed controls… are seen, or hidden).
Like you, I LOVE using percentages, whenever possible. More free-flow-ish. 
Some of your paddings were/are even in percentages! That is true dedication to percentages. Have you ever done any CSS work… using ‘em’ units? That’s a rush.
Stay tuned, but comment at-will, and teach us stuff you discover, Spanks. (thx)
I never wanted the header in the stackPanel, couldn’t get stackPanel under header; so thank you.
A manual solution is ok, I was getting tired of trying to figure it out. Was trying really hard to do so using percentages; didnt get far.
I havent really looked at the code behind adaptHeightToChildren, but ya, it should probably consider more then just the last child.
Marking as dirty onReady doesnt appear to do anything, even with all the heights & widths in pixels for the (child._height.isPixel) condition
Not sure which I hate more, css or php.
This became an issue around november. Prior to that the interfaces would stack correctly with the code in my playground, so something broke.
Thanks for the help Wingnut 
1 Like
Yep, I’m quite sure there were adjustments to stackPanels in the fall. I don’t know the details, but some github power searches could find-out. There may STILL be issues with stacks. Deltakosh loves to honor feature requests… cuz he’s really nice… but sometimes… phew… he tries to satisfy everyone. That leads to… you know… big code battles. 
1 Like
1 Like
