I’m attempting to use a TreeView to display presets, and I have a bit of an odd query. You can move the selection item-by-item with the up and down arrow keys if the component has focus. However, I can’t for the life of me find any sort of callback where I’m notified that the selected item has been changed.
The way I see it, there are two options:
Have a timer callback that checks to see if the selected item has changed, and changes the preset appropriately (this just sounds stupid now that I’ve typed it out; it made sense in my head though…)
Listen for key up of both up and down arrow keys, and load whatever’s selected on key up. This doesn’t sound as stupid as option 1.
I feel like there’s an obvious callback that I can’t find, but I’d like to think I could be forgiven since TreeView and its accouterments aren’t the world’s most obvious family of classes. Anyone?
well, when I figured out that solution, I didn’t spend too much time looking at the TreeView guts to see if there was any kind of callback. But I knew that TreeView::getNumSelected() could just be queried on a timer, soo… K.I.S.S., right?
querying a public member repeatedly is pretty simple in my view!
So in your derived TreeViewItem (that you have to inherit anyway) you can add a ChangeBroadcaster and make your TreeView or whatever you want to trigger the corresponding ChangeListener.
That’s how the FileTreeComponent does it (well, without the ChangeListener, but that’s easier IMHO)
Apologies to matkatmusic, but Daniel’s solution is what I was looking for. Don’t know how I missed it. I must have read past it 30 times. Hashtag old AF.
(Bonus: it works for both mouse clicks and keypresses. So I got to get rid of my isClicked override.)
More important than the docs would be the demo code. It sucks, because it’s all one-way, interactions telling the TreeView and Item what to do; there’s almost nothing in the code for getting information out of the TreeView. Since the demo code is the logical place to start for approaching these meta-Components and figuring out how they work, it would stand to reason that the demo code should, you know, do something.
(See also: the various list views, which exhibit the same “look at what we made! It doesn’t matter how it works!” approach.)
I think the mindset was always to extract data from the items themselves via inheritance, and not via the container (listbox vs listboxmodel, treeview vs treeviewitem, etc)
Hover, if you would connect two views to a model, I would place the selection rather towards the view than the model, but that is a case that can be argued…
The TreeView doesn’t follow the MVC paradigm, since the TreeViewItem is owned by the TreeView, so it cannot be used by different TreeViews anyway.
This is a rather theoretical discussion, and I don’t design the API, so I cannot comment on that.
I am just using what is there and am happy to share ideas, how to achieve your goals.