Okay, I’m having a spot of bother with the TreeView. Everything is super fine, but I want to have a right-click PopupMenu on the items. I’d prefer to keep it as it is presently (not using a custom Component), but it’s impossible to have a PopupMenu created in a TreeViewItem’s itemClicked function.
right-click an item to pop up a menu…
right click a different item to see its menu (automatically dismissing the first one)…
do this for a bunch of different items…
then if you finally actually dismiss the last menu [without selecting an option OR perhaps selecting an option] then ALL the other popup-menu return checks happen (for each item you clicked) which can be a serious problem depending on what you have happen in the menu options; for example - a ‘delete’ option may trigger a treeHasChanged restructuring, then the items yet to perform their response no longer exist.
So i’m going to just go ahead and create a custom Component… it should be neater i guess… but the notes in the docs make it sound scary!
- you should not keep a reference to the component
[ how does the component know that its item is selected if i’m not able to set a bool indicator inside it when the selection is changed? ]
[b]
the item may be deleted before the component[/b]
[ how severe is that?; it could be deleted at any time or it only matters in the destructors? ]
if i’m just going by the docs, i can’t see how it can be of any use to have a custom Component!
I think it is safe for the component to maintain a pointer to the treeviewitem it represents, as long as it only uses it in response to user interaction.
I.E running a timer inside the component may be bad because its treeviewitem may disappear without it knowing, but doing something like:
Thanks valley. That also means that i would need to have to access the owner item’s isSelected() function in the paint routine to draw the selectedness of the item; that initially struck me as quite unreliable, but i’ve not had any errors yet [storing a selected bool - on mouse clicks - in the component would not allow the cursor tree navigation feature to show selectedness].
someone do let me know if that is bad! thank you for your guidance.
Jules: i think it would be good to edit the documentation to describe this sort of process; at the moment it doesn’t make it look easy! People experimenting with TreeViews would do well to have tips like that; i.e. it’s safe to keep a pointer to the item, setSelected() in mouseDown() and use isSelected() in paint().
Good idea - I’ll add some extra help tips about that.
It is completely safe to keep a pointer to the treeview because the item components are owned and deleted by the treeview - so they can never exist after the treeview has itself been deleted.
btw, it looks like multi selection in treeview is not fully done…
(beware that’s a hidden feature request)
Looking briefly at the code, it looks like it just misses some changes in TreeViewContentComponent::mouseDown(), so that doing ‘shift’ + mouse down does a continuous selection from previous selection to that one, and ctrl + mouse down adds / remove the item to selected ones…
[quote=“thomas”]btw, it looks like multi selection in treeview is not fully done…
(beware that’s a hidden feature request)
Looking briefly at the code, it looks like it just misses some changes in TreeViewContentComponent::mouseDown(), so that doing ‘shift’ + mouse down does a continuous selection from previous selection to that one, and ctrl + mouse down adds / remove the item to selected ones…[/quote]
Ok, I’ll note that down as something to take a look at soon.
I know this thread is 10 years old, but I’m not sure these tips got added to the documentation.
It’s pretty unclear how to find out if your custom component is selected or not. Perhaps TreeView could be updated so that components are not kept around after the TreeViewItem has been deleted??