View Single Post
10/07/22, 04:19 PM   #1
ZOS_DanBatson
ZOS Staff!
 
ZOS_DanBatson's Avatar
Yes this person is from ZeniMax!
Join Date: Jul 2015
Posts: 171
ResizeToFitDescendents changes

Coming in 101037 will be a change to the behavior of ResizeToFitDescendents, something for addon developers to be aware of. Consider this code:

Code:
<Control name="$(parent)TestA" resizeToFitDescendents="true">
    <Dimensions x="64" />
    <Controls>
        <Control name="$(parent)TestB">
            <Dimensions x="70" y="70" />
        </Control>
    </Controls>
</Control>
In 101036:

In this example, TestA would initialize as 64 wide, but immediately the child would stomp that, and TestA would be 70 wide, 70 tall, and even shrinking TestB to thinner than 64 after the fact would not get TestA back to 64. The Dimension is fleeting. This was always a bad thing to do. Instead, the better thing to use was DimensionContraints. You could set a minX to 64 if that was your intention, and set both minX and maxX to 64 if your intention was to lock the width and only resize the height dynamically.

This old behavior didn't really have a realistic definition. The behavior was kind of undefined, resulting in ambiguous results. <Dimensions x="64" /> didn't really do an adequate job of covering intention.

In 101037:

<Dimensions x="64" /> now means "lock the width to 64 and only resize the height." Even though TestB has a width of 70, TestA trumps ResizeToFit for the x dimension with it's dimension of 64. The behavior is now explicit. This also means you no longer need to do the tedious thing of <DimensionConstraints minX="64" maxX="64" /> to achieve such an effect.

If you actually intended to lock the x and only resize the Y, it would also be good to specify resizeToFitConstrains="Y" to optimize the code so it can skip some unnecessary math steps, and to make it very obvious what you're trying to do. The resizeToFitConstrains attribute is new, and it will also automatically set resizeToFitDescendents to true when used. So the new code can look like this:

Code:
<Control name="$(parent)TestA" resizeToFitConstrains="Y">
    <Dimensions x="64" />
    <Controls>
        <Control name="$(parent)TestB" resizeToFitDescendents="true">
            <Controls>
                <Control name="$(parent)TestC">
                    <Dimensions x="70" y="70" />
                </Control>
            </Controls>
        </Control>
    </Controls>
</Control>
The result will be that TestA is 64 by 70, and TestB is 70 by 70. You don't strictly speaking have to use resizeToFitConstrains, but I do have an internal warning to catch cases where I use Dimensions without it to ensure that I'm actually using it to achieve the effect I'm expecting (and to catch old vanilla code that was using it wrong.) So it's very useful to explicitly document your intention/expectation.

Another change that's happening in conjunction with this is that Label controls cannot be marked resizeToFitDescendents. They now use the same underlying logic to achieve their auto resizing behavior, and that causes them to compete with each other. Any attempt to set a Label to resizeToFitDescendents will fail and throw a warning. It never really made sense to try to do this anyway, but now it's forbidden.

I mention this now so you can start looking through your own addons to see if you have any places where you were doing either of these things and expecting them to do something they will no longer do. If you were previously using dimensions as a way to force one of the dimensions, your setup will still work (better in fact, because it wasn't very stable before trying to do that.) But if you were expecting a child to let it grow past the dimension you set, it will no longer do that, and you should switch to DimensionConstraints instead.

Last edited by ZOS_DanBatson : 10/07/22 at 04:21 PM.
  Reply With Quote