Calling SetStyleAuto() on a UI element is translated to SetStyle("ClassName") where ClassName is the name of the UI element’s class. It then searches for the name in the xml file set in SetDefaultStyle(). If you subclass from Button for example and call the new class MyButton, calling SetStyleAuto() will search for “MyButton” in the default style. If you don’t have a style set for it you’ll get a white rectangle or box.
A solution is to either to call SetStyle("Button") to get the parent’s style, or to define a style called “MyButton” in the xml and customize it
Also, in the RegisterObject() method (if you made one) calling URHO3D_COPY_BASE_ATTRIBUTES(ParentClassName) after registering it is important to make sure the editor knows how to handle it.
Wouldn’t it make more sense if SetStyleAuto() were only to report the absense of any appropriate style, without clearing the element’s style, in cases where no suitable style is found?
When the style is not applied then you get a naked UI-element. The SetStyleAuto() is just a shorthand for calling SetStyle() with the class name as parameter. It does not perform the “clearing” first.
Probably worth to mention that the style can be inherited in the stylesheet.
I haven’t looked at the code yet in the UI Subsystem, but in my view unless we have changed how the style is applied fundamentally, otherwise what you proposed with the extra if exists check would produce exactly the same thing. Except, when you also add another else logic to, say, trying to get the name of the parent class via some kind of reflection and use the style of the parent class name.
But why do we need to go that far to achieve this? When someone derives a new class from a base UI class, it is most likely he/she wants to add more attributes or logic, and that would mean the style of the base class is actually not fit for the derived class. Granted it will make the derived class get some base style applied when its user forget to define the derived style for the derived class in the stylesheet file. Isn’t it the easier solution would be to do something like:
<element type="MyButton" style="Button" auto="false">
<attribute name="My Extra Attribute" value="true"/>
</element>
That also works, but when you’re prototyping (or simply don’t know about this) it can act as a safeguard. But in the end your solution is the most optimal
I wasn’t so much talking about subclassing actually. With little experience with Urho’s UI, my logic tells me it does not make sense to overwrite existing style settings with none as I imagine SetStyleAuto() would be most useful when iterating over a bunch of UIElements. One could make differently coloured themes that share a single base style that would always be loaded first. Elements without colour could be left out the settings for the coloured elements.
do what you need to do, ask what you need to ask, I for one will help you achieve it, but do not think for a second that urho is some kind of panacea - it hurts my head just asking about making moderate changes, let alone the harder ones. People around here are allergic to change, they think we carry in disease, they are closed of mind and their eyes are shaded, but this does not mean that I can not help you.