This is a really nice feature and makes some of my UI development so much easier, thank you!
I was just wondering, is it possible to expose the size that would be set if AutomaticSize was enabled in a read only property (similar to AbsoluteContentSize for the UI Layouts)?
My use case for this would be that I want to animate in a frame by making it “grow” in size from 0,0 at the centre - this can’t currently be done since AutomaticSize would override it! I would then be able to use this property to determine the size that the frame should grow to, and use that in my animation.
I also saw earlier in the thread about someone suggesting the ability to set an Animate property? I think exposing a property and letting us decide our own animation to apply in our code would make it much more flexible (but both these suggestions don’t necessarily need to be mutually exclusive!)
Hi @JohnnyMorganz - that’s a great suggestion! It would be handy to obtain automatically-sized dimensions without having AutomaticSize explicitly enabled. I’ll add it to our list of enhancements to consider for Automatic Size.
Thanks for your feedback and participation in the beta!
Looks like I was slightly wrong about the issue being totally fixed! I’ve started encountering what I believe to be the same bug but in a different situation from before. I think AutomaticSize does not properly account for UIPadding when calculating the size of automatically scaled text.
Here is a simple repro file. You’ll notice the text is again being drawn smaller than AutomaticSize thinks it is and thus sizes the label too large. The problematic TextLabel is called “Subtitle”. AutomaticSizeBugRepro.rbxl (25.4 KB)
EDIT: Hey, looks like I’m on a roll! Found another weird bug with AutomaticSize when elements are positioned past the bounds of their parent element. I don’t have the faintest idea why it happens. Here is a repro: AutomaticSizeBugRepro2.rbxl (27.4 KB)
I have a usecase of Automatic Size where I have a “Holder” frame (not using Automatic Size), and inside I have a UIListLayout, filling Horizontally and UIPadding. Within this Holder frame, I have several children (eg. think TextLabels) which are currently have AutomaticSize set to X (so for TextLabels, it would size to the text).
I wanted to have a final frame inside of here, with AutomaticSize set to X which would take up the “remainder of the space available” inside of this Holder frame, without overflowing.
From the OP, it says:
Controlling AutomaticSize Behavior
In addition to the enum property values mentioned above, the behavior of an automatically-sized element is indirectly controlled by the size of it’s parent GuiObject. The size of the parent GuiObject determines the maximum extents that an automatically-sized element can resize up to.
For example, a TextLabel whose AutomaticSize is set to ‘XY’ and is parented to a 200x100 Frame will resize up to 200x100, but no larger.
Currently, the UI does follow this, but because the maximum size used is the size of the Parent Frame, rather than the size of the “remaining space available”, it would overflow. I was wondering if this is something AutomaticSize could support - by instead setting the maximum bounds to space available?
I seemed to have found an issue where AutomaticSize doesn’t respect clips descendants of an underlying ScrollingFrame.
I have a Holder frame, with AutomaticSize set to AutomaticSize.Y,
inside of this Holder frame, I have a ScrollingFrame with AutomaticCanvasSize set to Y and ClipsDescendants set to true
As I add elements inside of the ScrollingFrame, if they start overflowing the current ScrollingFrame bounds, the CanvasSize is correctly increased, but it also increases the size of the Holder frame.
The final frame that you mention - the one that you want to fill with remaining available space - would it have child content? Or is the idea that the “filler” frame would simply use up whatever remaining space is available (regardless of its child content)?
That’s an interesting idea. Currently automatic size determines a min and max size and sizes to ‘fit’ the child content by using the min size. It sounds like you would want an ability to toggle the opposite behavior: instead of trying to fit the content (using min size), add the ability to change this behavior to prefer fitting to max size instead. Is that correct?
And then the other change would be this: changing ‘max size’ to be ‘remaining available space’ rather than simply the maximum size of the parent bounds.
Is that an accurate summary of your feedback? Just want to make sure I understand your use case.
Thanks for participating in the beta, and for your feedback!
Hi @JohnnyMorganz - there is an issue with automatically sized ScrollingFrame’s that also have automatic canvas size set. It sounds like this might be a related issue where an automatically sized parent of an automatic canvas size ScrollingFrame is causing erroneous resizing.
Hi @Ethanthegrand14 - A couple of critical issues came up that we have to address before releasing. We should have an updated ETA of when the full release will occur relatively soon.
Thank you for your patience and participation in the beta!
The latter would be correct in this scenario, I would want it to take up the maximum size available regardless of the content.
And everything else you mentioned would be correct too.
I understand this is quite an intrusive feature request, and I figured out a way to do what I originally wanted to do (without AutomaticSize) anyways, so I guess this is just an “optional extra” if you do wish to consider it, no worries if not.
When using a ScrollingFrame with AutomaticCanvasSize enabled, and a UIGridLayout inside the ScrollingFrame, the size of the canvas will ignore the UIGridLayout’s CellPadding, or any other type of Padding, and cut off some children of the ScrollingFrame.
Hello all! I have exciting news - AutomaticSize will launch (out of beta) on Tuesday, Feb. 16th! Be on the lookout for a forum post announcing its release.
Thank you all for the bug reports and feedback that you’ve provided during the beta.