I am often in a situation where I would like to modify some of the functionality of one of the built-in Unity UI components by simply inheriting/deriving from that class and then modifying/adding the needed methods. However, it is too often the case that a method or field I am in need of in my derived class is marked private instead of protected.
If there is not a good reason for this, I would like to propose that Unity go through their code and replace all “private” fields, properties, and methods with “protected”. Furthermore, in the case of methods, please mark them “protected virtual” so we can override them. Thanks.
I agree 100%. I was trying to modify the Text Script to allow it to scroll inside the text box itself. I had to copy the entire code from bitbucket repository, and manually do what you said. .Then I could inherit it and create my own version of it.
(Technically I think multiLine text are suppose to scroll currently, but there is a bug that causes them to display incorrectly and I didn’t want to wait on the bugfix
There are so many reasons to derive. Just a small list of components I have wanted to make but hit private road-blocks:
Animated ContentSizeFitter - so when items are added to a LayoutGroup the parent container animates to the new size.
Rect Button - pretty much a button that doesn’t do ray-cast testing on a graphic so you can have invisible buttons.
Hold Button - Button with press and hold functionality.
Auto-Resize InputField - Input fields that actively adjust width to match the content.
Advanced Toggle - Toggle with added functionality for sprite swapping, color swapping for on.off state. (this is a good example of why it’s important to derive from Toggle and not just make a new UI graphic type because I would like my advanced toggle to still work with ToggleGroups).
I am going to wake up this dead thread because I was just thinking the same!
Is there any reason Unity not to make private protected instead so we can actually extend these components without copying the code for an entire component to make a minor change!
(e.g. something simple like making a dropdown not fadeout (hard-coded!) and spawn an event on close
I mean, this being dependant on the used platform is downright dumb, and this is a matter of configuration that SHOULD be up to the developers to set for themselves if needed.
On a sidenote, I’d love for a lot of the Editor-side of classes and methods for UI to also be pulled out of private and internal scopes. If you want to make a new kind of control based on an existing one and want to add it to the Create menu for easy access and a similar configuration, good luck with that! To go back to the InputField as an example, I made a new InputField class and want to just easily add it to the scene via the Create menu.
For this you might want to use the DefaultControls class in the editor and make a method like CreateInputField, but half of the steps in that method rely on private methods you can’t reach!
My solution right now is pretty ugly: make a standard input field, then make a mock object with the custom input field, copy the component values over to the mock object, delete the original’s input field component, and then paste the mock object on there.
