Is testing the Parent name the best way to determine when a VisualElement is an internal VisualElement of the standard UIToolkit controls?

Unity Engine
, , ,
1

I need to differentiate between focusable VisualElements that I add to the UXML UIDocument and those that are inside UIToolkit predefined controls. For example, the TextElement of the TextField is Focusable but is internal to the TextField control as in:
image
I can test against the name of the contentContainer and see if it has the “unity-” prefix in it as in:

image
image632×177 17.5 KB

image
But I am wondering if there is a better way to do it?

2

[Update] I experimented with different ways to identify if a VisualElement is an internal VisualElement from a standard control and then I found that if I use Unity - Scripting API: UIElements.Focusable.canGrabFocus in a UQuery it will filter out the internals of standard controls, which is what I was trying to do. Corolary: focusable property in a UQuery does Not filter out the internals of standard controls.
Posting and resolving this hoping it will help someone else :slight_smile:

3

The elements that are greyed out in the UI Builder are elements that are added through code and do not appear in the UXML file. It’s not that they are internal (you could do the same with your own control), they are simply not editable from a UXML file standpoint.

That being said, for most complex controls, you want to create a sub-hierarchy for the control itself and choose which element “children” will be added to. For example, a Foldout will contain multiple children as part of its own hierarchy and will override the contentContainer property to decide where children will be added.

For a given element, there are two paths to adding an element:

  • ve.Add(child), which will add it to the contentContainer’s hierarchy (which can either be ve or another element).
  • ve.hierarchy.Add(child), which will add it to the ve’s hierarchy.

If you need to differentiate between elements you add in UXML and other elements, I suggest to add a uss class on it and retrieve them using a query.

Hope this helps!

4

I gave your filter (Where(element => element.canGrabFocus), right?) a spin, but I’m not sure how generally applicable it is as a solution. As I’m trying to integrate the AppUI package, I think I can say our environments are different, but I found surprisingly few elements are focusable by default. Toggling focusable in the UI Builder does allow for their selection, but then you might as well add a uss class with no side effects, as suggested.

My solution was merely to use the regex @"^[a-z]+([-_]+[a-z]+)*$" and filter out “most” control elements by their name (app-ui controls do not all begin with unity).