RegisterValueChangedCallback triggers for childs as well

While working on my own implementation of a slider with field I stumbled upon something I found strange and made it hard to get my slider working. I'd like to hear from Unity Devs about what they are thinking. The issue is following: RegisterValueChangedCallback also triggers when children change their value. An example and explanation:

Code (CSharp):

1. var outerField = new FloatField();
2. var innerField = new FloatField();
3. outerField.Add(innerField);
4. outerField.RegisterValueChangedCallback(x => Debug.Log(x.newValue));

Changing the value of the outerField results in 1 callback. This is expected.
Changing the value of the innerField results in 2 callbacks. I expected zero.
Is this intended? I know events bubble up, and that doesn't have to change. I can always use RegisterCallback if I want to use the event system. But I feel like RegisterValueChangedCallback should only be called when the value of the field I actually registered to changes. It just feels a lot less confusing and there's nothing lost in my opinion.
Also, I know the example above seems artificial because no one would nest input fields like that. But in my case I wanted to create slider with a field. My idea was to create new class inheriting from BaseField<float> which has a Slider and FloatField as children. It listens for changes in it's children and applies them to itself. But this lead to the above mentioned issue that the class I created would give two callbacks: One for child that has changed and one for changing the value on itself.

 

Thank you for your response. I know StopPropagation, but I think I didn't properly articulate what I was getting at. I'm proposing the idea that RegisterValueChangedCallback should behave differently by default. As mentioned in the example above, I get 1 callback (not 2, my bad) when changing the value of the innerField. In my opinion this is confusing. I want to illustrate with another example how confusing this can get:

Code (CSharp):

1. var floatField = new FloatField();
2. var intField = new IntegerField();
3. floatField.Add(intField);
4. floatField.RegisterValueChangedCallback(x => Debug.Log("outer: " + x.newValue));

This is a simple script I created. When I change the value of floatField, I get 1 callback. When I change the intField I get no callback. As a developer I expected this. Why wouldn't I? Now I'm deep in development, changing code in different places and refactoring, when I realize I want to change the IntegerField to a FloatField. Happy with the quick progress I have made with the incredible UIElements already, I realize I can simply change the class to FloatField. Right? Wrong. I suddenly get more callbacks than before. I get callbacks when changing the value of the inner element.
Now think bigger, a huge editor with lots of dynamically created fields. I add more and more fields as children to the container, some TextFields, some VectorFields etc. I suddenly get more callbacks on the parent when changing the value of their children that coincidentally have the same ChangeEvent. It's horror to track down.
And if the developer really wants this behaviour, he/she can still use RegisterEventCallback<ChangeEvent<float>> and trust that it works as the Event System does.

In the end it just comes down to naming and expectations. floatField.RegisterValueChangedCallback just reads as if I will only get changes from the floatField. Renaming the callback to RegisterValueChangedEventCallback could also alleviate some confusion, though possibly not much.

Just a developers two cents.

 

Thank you for your response and your patience with me. This makes some sense, and accepting "Fields were never meant to have children" as a fact then I guess that's fine. But as a last question related to this one: How would you create a compound element, like a slider with a field? Because with all my ideas I run against a brick wall.

• Solution I started with: custom class that inherits from BaseField<float> which has a slider and a field as children. This is apparently the wrong way, since it shouldn't have children
• Either make Slider or FloatField the parent and attach the other. Same issue as above, a field shouldn't have children
• Custom class inheriting from UIElement which has the slider and field as children. But this is also annoying, because it doesn't act as a single element, so I can't bind properties, call RegisterValueChangedCallback etc.

I feel like I'm overthinking, but this doesn't let me go. Really curious what the inteded way of doing this is. Perhaps I should just wait until you release the slider with fields yourself

 

Hey uDamian,

Thanks man. I really appreciate the time you take for your responses, it helps a lot. Didn't have time to work on my scripts today, but this is something I wrote a few days ago which basically works, but I want to refine it at some point. I'll update it in the next few days with the info from above. And yes, unfortunately I have to use reflection to update the visuals of the slider.

Code (CSharp):

1. public class SliderWithField : BaseField<float>
2. {
3.     public Slider Slider { get; private set; }
4.     public FloatField FloatField { get; private set; }
5.  
6.     public override float value {
7.         get => base.value;
8.         set {
9.             SetFieldValueWithoutNotify(value);
10.             SetSliderValueWithoutNotify(value);
11.             base.value = value;
12.         }
13.     }
14.  
15.     public override void SetValueWithoutNotify(float newValue)
16.     {
17.         SetFieldValueWithoutNotify(newValue);
18.         SetSliderValueWithoutNotify(newValue);
19.         base.SetValueWithoutNotify(newValue);
20.     }
21.  
22.     public SliderWithField(string in_Label, float in_Start, float in_End) : base(null, null)
23.     {
24.         EventCallback<ChangeEvent<float>> callback = (evt) => { value = evt.newValue; evt.StopPropagation(); };
25.         Slider = new Slider(in_Label, in_Start, in_End, SliderDirection.Horizontal);
26.         Slider.style.flexGrow = 1f;
27.         Slider.Query(className: Slider.inputUssClassName).First().style.marginRight = 4;
28.         Slider.RegisterValueChangedCallback(callback);
29.         FloatField = new ConstrainedFloatField(in_Start, in_End);
30.         FloatField.style.width = 50;
31.         FloatField.RegisterValueChangedCallback(callback);
32.  
33.         // TODO: this feels dirty :(
34.         this.Remove(this.Query(className:inputUssClassName));
35.  
36.         this.Add(Slider);
37.         this.Add(FloatField);
38.     }
39.  
40.     private void SetFieldValueWithoutNotify(float in_NewValue)
41.     {
42.         FloatField.SetValueWithoutNotify(in_NewValue);
43.     }
44.  
45.     private void SetSliderValueWithoutNotify(float in_NewValue)
46.     {
47.         // I need to update the slider because it won't get updated properly
48.         System.Reflection.MethodInfo mi = Slider.GetType().BaseType.GetMethod("UpdateDragElementPosition", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic, null, System.Reflection.CallingConventions.Any, new Type[0], null);
49.         if (mi != null)
50.         {
51.             Slider.SetValueWithoutNotify(in_NewValue);
52.             mi.Invoke(Slider, null);
53.         }
54.         else
55.             Slider.value = in_NewValue;
56.  
57.     }
58. }

 

If I remember correctly, I've also encountered similar situations like this with nested value change events. One of the things I did to isolate them was to check if "event.target" is the correct element in the actual callback.

For example:

Code (CSharp):

1. var parent = new FloatField();
2. var child = new FloatField();
3.  
4. parent.Add(child);
5. parent.RegisterValueChangedCallback(evt =>
6. {
7.     if (evt.target == parent)
8.     {} // Do stuff
9.     else if (evt.target == child)
10.     {} // Do other stuff
11. });

At least I believe this works!

 

Compared to the UI_canvas system, this is an insane of work just to get a value from a slider