Feedback ListView Bindings

I've been playing with the new ListView bindings in 2019.3, but there seems to be one real big flaw - it's including the array size in the list, and I'm not sure why it's been built that way.

I went digging into the source code reference to figure out what was going on, and saw that this seems to be intentional behaviour? Here's the code in question; ListViewBindings.cs:39 in the SetBinding method



Unfortunately, I can't see any way round this, other than checking the index within my own bindItem method, and hiding the row if `i == 0`, but that leaves an empty space so isn't really any good either.

I believe this should either be disabled entirely, or an extra property should be added to the list view to control this setting.

Any work arounds for the time being?

 

Damn, that's a darn shame.

Everytime I try to do anything with the binding system, it feels lovely to get set up, and then rapidly becomes absolutely infuriating.

Is UIElements really ready for us to start using? I keep trying to use it for new editor tools where it seems a perfect fit, then end up spending weeks smashing my face into a brick wall of nightmarish issues.

 

Thanks for getting back so quick!

I understand, it's a huge amount of work to build the UI Elements system, and it's pretty darn great so far. I realise that I meant to say "UI Elements binding system", which I realise is quite different to what I wrote. The rest of it's been a pleasure to use, especially coming from a web background myself.

Most of the issues I've experienced related to using complicated binding and lists, which the more I look seem to be the most experimental aspects of the new system. I'm wondering whether I would be best to try to avoid the binding system when working with lists in future.

As for specific feedback, this is what I'm currently facing (Looking at the recent work on list binding, I imagine you're already aware of similar friction points):

• Get the SerializedObject/SerializedProperty from binding. I've seen that in the ListView bindings you have a bindItem setup - I'd like to implement similar things.
  • Right now I've got some super ugly reflection going on to access the binding SerializedProperty/Object. It's BAAAD.
• Bind an array to an element; Even without value binding, if you could get a binding reference and then access the SerializedObject, you could manually bind child items easier.
  • I've attempted binding through the array size, as suggested elsewhere, but this resulted in issues when the element contained integer property fields, as the change event from the child fields would bubble into the List, and destroy all the bindings. I'm now relying on an invisible nested integer field bound to the array size, with a custom change callback, coupled with some reflection

These new APIs are an incredibly good step in the right direction, but they don't quite feel intuitive yet. Either that, or I'm the annoying user hitting all the weird edge cases

 

Absolutely, but that didn't quite work out in my instance

1. The fields are generated from a PropertyDrawer to make the component more reusable, so I can't predict which fields I'll need to do that too. The event may also need to be processed by a parent component.
   
2. The issue was the change event being processed by a callback registered by the binding system, so I was unable to check the ChangeEvent.target property.

I couldn't really see any other approach to this issue than the one I chose. I think the binding system should probably have something in place to prevent it from processing a change event for a different property.

 

Thanks! That's a nice idea, and does give me some thoughts. I think for this specific one, I'll keep hacking away with the binding systems for now - if I pretend that I'm not using reflection to access internal properties, then this is almost a nice solution; it still works with generating UI for bound elements, just a bit chaotically.

I do think this discussion somewhat highlights where the issues lie with the UI Elements system; It's powerful, and does a lot, but there's some strange holes here and there, which require some weird and wonderful work arounds.