It is a bit of a special case, and I can see why you would want to not keep all treeViewItems in memory normally, instead creating and destroying them as the tree is scrolled, as is the current behaviour.
BUT, in my program I have many custom components, some of which have state that I want to keep. I won't get into too many details on this, but it's not the kind of state that makes sense to keep in a model, since it only affects the view, not the model itself...
Also, some of those components are a bit heavyweight, and I'd rather just keep them alive and not have them created/deleted all the time, since the treeView does not contain all that many treeViewItems...
Is there a way of turning off this creation/deletion without cloning the TreeView code that I've overlooked?
When I try that I get Access violation error inside the RowItem contructor when I scroll.
I haven't tried making a simple example to test if it happens also in there or if it is just my code causing it yet...
No matter, I'll try that up next, or perhaps just bite the bullet and store the custom component state in the model, it might come in handy up the road :)
I’m creating some custom midi regions in my treeview. If I select one that’s in view and then scroll so it’s out of view and I select a different, any that are previously selected have been deleted and I end up with some EXC_BAD_ACCESS errors when code that deselects them is called. Even tho i’m checking for nullptrs, this still happens.
Is there a way to make the treeView not delete a selected item even if it’s not in the viewport or visible?
The solution I ended up with for the cases where I absolutely needed the TreeViewItem and Component to share data, was to maintain a third object that they both wrote/read from, which persisted.
You COULD alternatively use WeakReference to point to the Component, and use a messagemanagerlock when accessing the component you get from the WeakReference to make sure the Component is not deleted after you’ve gotten the reference to it… But that is potentially very inefficient, unless you hold the lock for very brief amounts of time.
