I need to position a set of widgets horizontally in a panel. The choices I face appear to be: Horizontal Box, Canvas, Wrap Panel, Overlay, and maybe even Grid Panel. The problem I’m having is that each child needs to be slightly overlapped on it’s left edge by the widget that precedes it and that overlap needs to have the widget on the left needs to have a higher z-order than what it is overlapping. I need the widgets in sequence from left to right so the Horizontal Box would appear to be correct but it has no z ordering. Overlay has z-ordering but no x-ordering when you drag a widget into its hierarchy. Canvas has its own issues but it’s the only one I found so far that has a built-in z-order. And Wrap Panel doesn’t have z-ordering either. The left shifting I can do with a negative padding (tested), but the z-ordering is vital. Any suggestions?
Wow! 24 views by this point and more than 12 hours later and no reply. I figured at least an Unreal staffer might chime at some point. I didn’t know this was a difficult or impossible question. I guess I was more hopeful than could be expected.
There’s more than one way to approach a problem. I’m trying to picture your issue. Do you have a screen shot of what your issue is? I know you can do some overlays (just on the canvas) and have them overlap, but it really depends on the end result you are trying to achieve.
I can get a screen shot, yes (or part of one anyways). But let me get another image that better exemplifies my goal:
See the slight overlap on these tabs? I’m styling a custom tab control:
And here is a snippet of the actual shot using a Canvas panel for placement (yes there is a separate row of the same widget type beneath, but it’s in another container).
Each of these tabs are a widget within a parent widget. When a tab gets focus the material changes slightly (from having a bottom edge line to none) and I need to move it upwards in the z order. Code-wise I need to iterate through the containing widget and order is important because the index is used to select a widget switcher.
My advice is to make your own tab well SWidget. The stock controls are under the impression it’s unnecessary to overlap because they’re trying to maximize batching.
“tab well SWidget”? I’m a bit confused by that phrasing. Typographical error, Nick? I’m actually creating a custom tab Widget, it’s the collection container that I have to put it in that’s stumping me.
Not a typo. A “Tab Well” is a common name for what you call the area where the tabs live. I don’t mean creating a custom tab widget, but a new SWidget panel that deals specifically with your tabs. This is the approach we use in the editor.
Basically you are telling me to jettison UMG, and go to Slate (I had to stop and look up “SWidget”) and C++. How many additional hours of development time (learning the API, coding, testing, and training team members - who are not skilled in coding - in its usage) do you calculate would be consumed as a consequence of this route? Engineering is a non-recoverable cost in both time and money and outlays of this nature need justification, especially if facing a narrow time window for production. If you go to the online docs under the Slate UI section the first thing encountered is this highlighted text:
(Link is at https://docs.unrealengine.com/latest/INT/Programming/Slate/)
Drilling down to the Motivation section we find this:
And of course I’m working on a data-driven model. If you find yourselves resorting to a hack that your own documents caution against you are probably dealing with a design flaw somewhere. 
I’m suggesting you make a new kind of panel in Slate. Which is how UMG works, new panels are not intended to be implemented in blueprint code, the layout and drawing would be both too complicated and too slow to be implemented in blueprints. Therefore if you need a new type of layout panel that treats the children in a special way you should make a new Slate panel, and wrap with with a UWidget/UPanelWidget.
Slate and UMG are inseparable, to take full advantage of UMG, one must sometimes delve into C++ and extend what is possible with the underlying Slate framework at times.
That’s cool. Those comments in the docs were amusing under the circumstances though. I’ve been a embedded systems programmer working in low-level assembly code in telecommunications. I’ve been in worse situations. I’ve been wanting to get deeper into the framework but just haven’t had the time as of late. Thanks for the advice.
I’ve decided that I’m stuck with Canvas. Slate is NOT a viable option on several levels, not the least of which is poor documentation. I’ve had the luxury of working in more complete UI systems and I guess I’m a bit spoiled.