DragAndDrop from component that don't persist

gui

#1

I am having an issue with drag and drop that I after many attempts I have not been able to solve. I have a component inside a custom tree (not using the juce::TreeView) that I need to be able to drag and drop. However, there are events in my program that can cause that particular component to get replaced by a different one mid-drag. I don’t want to get into a discussion on why I am doing this, so let’s assume there is no other way to implement my system.

The issue is that when the component that triggers the original mouse event gets replaced, no mouse event is tracked, and therefore my drag and drop freezes in place until I let go of the mouse button.

I’ve tried adding a persistent mouse listener to this component, in the hopes that it would send the mouse events to the drag and drop system. This didn’t work.

I’ve tried persisting the original component, but it necessarily gets re-parented and the drag and drop is also lost anyway. This didn’t work.

I’ve tried creating mouse events based of the original…but apparently this is a big no, and doens’t work. I really hope this is possible in some way or another, because not being able to manually start a mouse event leads to some very big (tangential) issues.

Thank you for taking the time to read this. I’ll keep trying to find ways around this, and try to understand exactly how JUCE manages mouse events in the meantime.


#2

It’s difficult to say without seeing the code, but instead of replacing the original component during the mouse drag could you just make it invisible with setVisible (false) and then replace it when the drag ends?


#3

Yes, we do this in places.

Another alternative might be to start your drag operation from a parent component (maybe the actual tree component) that doesn’t get deleted. You can always make your drag image whatever you like.


#4

@ed95
I’m trying to figure out how I could show code in a way that would make sense, but it’s quite hard because there are so many different components. It’s possible that this could be avoided if I don’t regenerate every single node every time the model changes (i.e., the node persists). But I’d like the system to not care about regenerating the UI tree and be more robust for cases where recreating that node is inevitable.

The issue with making it invisible is that the node is part of a subtree, so it inevitable gets reparented. My assumption is that once it becomes reparented I lose the DragAndDropContainer. Otherwise this would be an ok solution. This is basically what my second attempt consisted of–keeping a shared pointer of the component while it is being dragged. Maybe I did this incorrectly. I’ll try again, perhaps I can find a way to keep the component as a child of the tree itself.

@dave96
I may be misunderstanding something about how drag operations start, but even if I start the drag operation from the tree itself, the drag seems to track the original event from the node. In other words, once the node disappears, the event stops and the drag freezes in place (the drag seems to still be active, it’s just the position that doesn’t get updated. Maybe something else in the code is causing the mouse event to not be tracked anymore once the source component is lost. It’s good to hear that you are doing this though, since it gives me hope that there is a solution.

Thank you both for your replies.