Widget order

[anonymous-edc (Anonymous User)]

Hey,

We have an application that uses different layers of UMG widgets. In some cases the z-order of the widgets is getting wrong. Found a post here describing the issue and a solution

500×500 2.84 KB

Hello, You would be correct in assuming that you will need to set the Zorder for everything on your Designer tab that overlaps. Hierarchy does not necessarily determine what shows as on top. As for rearranging widgets in the hierarchy, you will need to click and drag them. When dropped on a widget that can hold it as a child widget the widget will then be placed under it. You can also reorder the widget by clicking and dragging them upward in the hierarchy.

Does this makes sense, and can we get this fix into the Private-HMI-4.27 branch?

br

//Jonas

[Attachment Removed]

[anonymous-edc (Anonymous User)]

Hi Jonas,

Using StableSort instead of Sort does make sense to keep widgets with equal ZOrder from changing relative positions among themselves. More recent versions of the engine have also shifted to StableSort (see CL 14293120 / git commit 034c105). Another solution, which might offer an even stronger guarantee, is to edit the sort functor FSortSlotsByZOrder to consider FChildZOrder::ChildIndex as the tie breaker (see CL 2581223 / git commit 9a388ac).

Hope this helps!

Best regards,

Vitor

[Attachment Removed]

[anonymous-edc (Anonymous User)]

Thanks Vitor!

I think the root cause in my case is the “Slate.EnableGlobalInvalidation=1”. See if we take in these changes above also, seems “good-to-have”

//Jonas

[Attachment Removed]

[anonymous-edc (Anonymous User)]

Hmmm… There is actually another CL that deals with a Z-Order issue specifically when using Global Invalidation, but I’m not sure that it will be mergeable to your branch without conflicts. If you want to try it, it is CL 18532146 from the 5.0 branch (GitHub commit aedcf55).

Let me know if you decide to try it and if it helps!

Best,

Vitor

[Attachment Removed]

[anonymous-edc (Anonymous User)]

Cool, well that change is quite different (event the start commit), so don’t think I dare I checked the other you mentioned (git commit 9a388ac), seems as that is already ported, so have those changes.

[Attachment Removed]