ExpandeableArea not respecting scrollbox

Development Platform & Builds
, ,
1

Collapsed:

223490-before.png

Expanded. Note: it is placed inside a scrollbox but acts as if there is no scrollbox upon being expanded:

223491-after.png

Expected:

223492-expected.png

I reproduced it in an empty project (note that it (sometimes) already bugs in the designer). Note that it even shows as expanded in the designer when it is in fact collapsed (could be another bug):

223493-reproduced.png
223493-reproduced.png1781×866 168 KB

And here is a workaround that ‘fixes’ both bugs:

223494-fix.png
223494-fix.png1796×879 158 KB

The “fill” option should have nothing to do with it actually containing the ExpandableArea within the scrollbox but it does. And it is also the workaround for now to get a large ExpandableArea to work in a scrollbox.

I have a small empty project where I reproduced it in if you need it. But should be simple to reproduce.

2

This looks like a pretty obvious bug providing that SizeToContent is ticked. Some containers do act up when the children size changes.

  • Ensure that SizeToContent is ticked. For you it might be in the vertical box that houses the scrollbox, not sure.

  • If it still acts up, and you’re after a workaround for the time being, try ForceLayoutPrepass (I think that’s the name) on both the Scrollbox and the vertical box after ExpandableArea has been unrolled.

I’ve been using ExpandableArea inside (just) a vertical box and never noticed that. The issue you described might be Scrollbox related.

3

There is no SizeToContent option for the ScrollBox nor for the ExandeableArea in this particular case (makes sense because of how they are nested in the WidgetTree. So that option disappears).

I haven’t tested the ForceLayoutPrepass because well, my current workaround (set size to fill) is acceptable to me for this particular case.

4

There is no SizeToContent

It will be in the Border, judging by your setup.

5

Ah I see you meant that one. Yes that works because the window itself will simply resize but this beats the whole point of using a ScrollBox. It creates an enormously long window that goes off-screen (and no scrollbars) in order to attempt to resize to that content. Not a viable workaround for my case.

Also (off-topic) I get editor crashes on a regular basis (not sure how to reproduce) when clicking “compile” after adding other common (non-custom) UMG widgets to the ExpandeableArea inside the ScrollBox:

223516-constantcrashes.png
223516-constantcrashes.png1205×502 29.8 KB

There at least one more bug related to the ScrollBox + ExpandableArea combination. I work around this one by adding 1 component at a time, then I compile and save and add the next one. If it crashes I just restart and continue and pray it won’t immediately crash until I have all components that I need.

There was also another crash related to it but I forgot (is rare). I’m not getting this “stable vibe” around UMG’s.
UPDATE: I remember it again. CTRL+Z can also cause crashes in the UMG editor.

6

but this beats the whole point of
using a ScrollBox. It creates an
enormously long window

Yeah, my bad - it made no sense, true! Just ignore what I said.

Undoing actions in UMG is crash-prone, that’s for sure.

7

Hello,

Thank you for submitting a bug report. I have reproduced this issue and logged a report for it here

You can track the report’s status as the issue is reviewed by our development staff. Please be aware that this issue may not be prioritized or fixed soon.

Thanks