first off, thank you very much for helping me out in another Thread ,LostDog-FoundCat .
I have some more questions and figured this would be best packaged in a new one.
Currently i managed to populate a TreeView for Runtime, so that it displays what i had in mind.
I use a plain c# object instead of an interface for TreeViewItemData , is this alright or will i run into some Performance issues or other Problems? I do this to have different classes in 1 Treeview without the need for them to share 1 Interface (so i can add custom elements, depending on the classe later on).
Here is the bindItem code for this:
// Set TreeView.bindItem to bind an initialized node to a data item.
treeV.bindItem = (VisualElement element, int index) =>
{
if (treeV.GetItemDataForIndex<object>(index) is sdGalaxy g)
{
(element as Label).text = treeV.GetItemDataForIndex<sdGalaxy>(index).Name;
}
else if (treeV.GetItemDataForIndex<object>(index) is sdSector s)
{
(element as Label).text = treeV.GetItemDataForIndex<sdSector>(index).Name;
}
// todo: add case for Cosmos HERE (this is why the screenshot has an unnamed element at top)
else if (treeV.GetItemDataForIndex<object>(index) is string G)
{
(element as Label).text = G;
}
};
I understand what the TreeViews item “Func”'s do. But i couldnt find examples to when to use them or to ignore the.
2.1 makeItem => clear, the Visualizer/Virtualizer of the Tree detected that this item is need AND visible, use this to Generate the Container for this Item. This is needed for Container and Display.
2.2 bindItem => clear, the Visualizer/Virtualizer has detected some change that makes this Container visible AND/OR change Content. This is needed for Content Change and Display.
2.3 unbindItem => not clear. When should i supply this Func with code? My simple example seems to work just fine without it.
2.4 destroyItem => not clear. When should i supply this Func with code?
It is my understanding that when i screew up with those 4 itemFuncs properly, i can crash the application ? Like stuff gets bound without proper unbinding while the user scrolls wildly around?
Feedback: The documentation should mention that 1 Treeview needs 1 unique key for each element in the Treeview, no matter the nesting levels. I hope i didnt miss this information somehow.
Feedback 2 I would suggest to Rename “bindItem” and “unbindItem” dearly to something else, like “supplyItem” and “unsupplyItem”. If Data Bindings are to come, this is begging for Problems and Support help requests, it also makes searching a bit harder.
Hey there - thanks for bumping this up - for some reason I wasn’t alerted to the first posting of this last week. Let me do some digging and see what I can find
1- There shouldn’t be any problem using plain C# objects. One thing though; you can use the result of the is operation to avoid doing two queries:
if (treeV.GetItemDataForIndex<object>(index) is sdGalaxy g)
{
(element as Label).text = g.Name;
}
2.You would typically use unbindItem or destroyItem if you registered event callbacks during make/bind item that need unregistering, or if you are using additional element pooling on top of the virtualization for example.
Do you have an example of code that would crash the editor? Items are virtualized so the binding code needs to watch out for any recursive paths or registering multiple times the same event.
Sure, we can add a note in the scripting API and the manual. Thanks for the feedback!
This is indeed an annoyance we have internally when talking about the multiple binding systems too . I can bring that concern to the team. API changes take a few versions to be completed entirely because we don’t want to break user code, and these changes cannot be backported to older versions for the same reason, so this would most likely take some time to happen.
Thank you very much for this detailed Information.
For 3. i had in mind just the case you described in 3/2, where i would subscribe but not unsubscribe during scrolling.
And with egnouth scrolling while subscribing to anything, i thought i would reach a cap.
But Since you mentioned not only “unsubscribed” case but also recusrion, i think this covers it.
So unless i understand it wrong, your awnser 3 tells me i could, but shouldnt, ignore unsubscribing in “unbind Item” ?
Another problem showed up. The TreeView has indent levels, but i can not find a proper to way to manipulate them.
When i use uss, it gets ignored ( based on this Info ) as it should because it say “inline” in the debugger.
The width of the indent needs to be computed because it can change from line to line as the items are reused and virtualized. We use the width of the foldout arrow to calculate this indent. That width seems to be a lot larger by default in Runtime, hence the large indent.
By changing the style of the toggle arrow, you should automagically have an updated width for the indent.
Though it’s a good point that the relation is not clear between the two. We lack documentation there. We could also support to set indent width with a uss variable, maybe that would help (and would also allow users to have 2 different widths for indent and toggle. Feel free to submit a bug if that’s a missing building block for you.
I would suggest to Rename “bindItem” and “unbindItem” dearly to something else, like “supplyItem” and “unsupplyItem”. If Data Bindings are to come, this is begging for Problems and Support help requests, it also makes searching a bit harder.
