Next week, we are planning to add a new property called ContentText to Text Objects. (The property is a ReadOnly string that shows you what is being rendered by the current text object without extra formatting tags.) In order for all of your places to function correctly, please make sure you are not accessing children with name ContentText under text objects directly through .ContentText.
For the sake of both code functionality and API safety, we always suggest getting reference of an exiting child using the following code:
The thousands of lines of code Iâve written over the years could easily cause this to break. I doubt I probably used ContentText anywhere, but if any of my old games break now we know why.
Using FindFirstChild to work around new property names is definitely clunky and we need some way of making Roblox realise we want to access a child, not a property. I just dont know how feasible this is.
Many frameworks such as Fusion implement this using a Children descriptor symbol (since Children itself is a deprecated copy of GetChildren) to access children. (Though I dont want to be typing Part.Children.Part2.ChildrenâŚ)
The solution in the engine space is generally to offer some kind of path selector DSL, which can double as a way to let you quickly find and iterate sets of children of particular type / with particular tags and attributes in addition to accessing single children. Itâs an idea thatâs been thrown around occasionally.
Currently, if you try to make a Typewriter (the thing that goes through the text and looks like itâs âtypingâ out the words) that supports rich text, youâll run into an issue; If you want to stop the typewriter once itâs reached the end of a stringâs worded content, youâll have to know how long the string is. And unless you create some hacky way to omit RichText tags, you wonât know how long the actual âcontentâ of the string is.
I still think âRenderedTextâ would be a less intrusive, yet more clear, name. ContentText alone doesnât really say much for someone without much context behind the property.
Thereâs a new property called ContentText applying to text based GUI objects. Thereâs a chance some GUIs have a child element named this and by default, Instance properties are looked for before looking at their childrenâs names when indexed. For example, if you name an Instance called Parent underneath a script, trying to access it would return what the script is parented to, NOT the Instance named Parent due to it already being a property of the script.
While your proposed solution would probably eliminate any issues, as it is not likely anyone has an instance named GetTextContent; youâd be removing the ability to listen to ContextText changes using :GetPropertyChangedSignal.
This will be invaluable to bind effects to text, and its not something I want to miss out on.
Itâs not that simple due to rich text. The Text property of text GUIs will include characters that arenât actually part of the text displayed to the user and only serves the purpose of formatting the text the user sees.
Itâs a single property that only gets updated (presumably) whenever you change .Text, adding some option to disable this property would likely be more wasteful than just leaving this property always on.
