Some UI I wanted to make without fully scripting it
The little arrow image is square, so I apply some padding to the right of the text:
Scale does not work
Even if you use a UIListLayout, if the aspect ratio of the whole UI is not constant, then you need to use Offset along with some code to get it right, unless there is an other obscure constraint I overlooked or don’t know how to use
Even so, when UI is very dynamic, with animations and stuff, it’s really nice to make the UI inside a script, and use offset
There is a point to not use scale, to some people at least
I think that is because you are ussing the funcion Udim2.new() instead the Udim2.FromScale().
Both return an Udim2 but look: On your code (line 8) you are using Udim2.new(0, YSize) giving 0 as the first argument (X Scale) and YSize as the second argument (X Offset). I think that the problem is that you are giving the YScale to the X Offset. And since it will prob be <1, it gets truncated to 0.
The code is specifically using offset, not scale, because scale can’t be a constant (as it would be messed up if the aspect ratio changes, would need to be recalculated) and offset is easier to work with.
All that code does is take the vertical size of the TextButton, in pixels, and update the UIPadding’s PaddingRight. And the value is not smaller than 1, because it works… The text in the text button does not overlap with the arrow, which would happen without it
I am purposefully giving YOffset (AbsoluteSize.Y) of the TextButton (not YScale) to the X offset, because that is about the size (in pixels) of the arrow (which is square)
I am pointing out the limitations of using scale and constraints, as opposed to using offset
The size of the arrow is dependent on the Y size of its parent, and so does the X size of the arrow, because of the UIAspectRation constraint it has
Now, the text spans the whole length, minus the size of the arrow.
Now lets say the screen window resizes along the X axis only, so the viewport size X is bigger, but the viewport size Y is the same.
In this case, the size of the arrow has not changed, but the length of the UI has.
Lets say, the size of the arrow was 10 pixels, the length of the UI 100 pixels, and so, the length of the text 90, or 0.9 with scale.
Now, after the screen size was resized along the X axis only, lets say the length of the UI is 150 pixels. The arrow remains at 10 pixels. With the same scale of 0.9, the text would now be 135 pixels in length, while it should actually be 150 - 10 => 140 pixels.
Then you could make a TetxLabel inside the frame for the text and an ImageLabel for the Arrow.
When window dimensions change, you could make the text scale all the Y of it’s parent and all the X -the space used by the arrow (in offset).
Anyways, In my opinion there isn’t any reason of use scale in buttons to open Frames. (Normally) I only use them on the frames wich should fill all the screen.
