No events when drag target is removed from the scenegraph while dragging

[Sebastian Rheinnecker]

Hello Richard,

we found a workaround that is suitable for our usecase: We found out 
that the DragEvents still reach the node even after it was removed from 
the SceneGraph, and those events luckily contain the correct mouse 
coordinates. Using a temporary event filter that tunnels the DragEvents 
from the ghost-node to the components of our application that needs 
those, we resolved our issue.
However, if this behavior is going to change in future versions of 
JavaFX, it would be nice to provide a more "official" solution to this 
problem, so I filed a jira issue regardless (RT-32417).

Kind regards,
Sebastian Rheinnecker


Am 16.08.2013 18:31, schrieb Richard Bair:
> Yes we will need a JIRA. You can think of this the same way as a normal mouse press / release event pair. When you issue a press event, you will/should only get the release event on the same thing that got the press (since these events are paired). So if on a press event you remove the pressed node from the scene graph, what would you expect the release event to do? Likewise, if during a drag you remove the node from the scene graph, I'm not sure any option other than what we're doing would be any more consistent or correct (likely less so, while also being more complicated).
>
>> well, the behavior we are looking for is being able to proceed with a drag after the thing on which the drag started changed (got removed / replaced). It doesn't sound very convenient for me that a thing that is not in the scene graph anymore can still the mouse capture, which means that no component of the whole application receives any mouse events at all. I think that it is not an uncommon scenario for an application to change things when a drag is detected.
> I think it is uncommon to remove the dragged node though and expect drag events to continue (because there are paired events. If you just deliver drag events to whatever is under the mouse, you will have very unexpected behavior without also getting the paired drag started / drag ended events?).
>
> What I would recommend is that you place the node you're going to drag in a group, and handle the drag events on the group. Then you can remove the node that appears to be getting dragged, because it isn't actually the one getting the drag events.
>
> For example, I could have a group and 1000 nodes within it. Each of the 1000 nodes would have mouse enter / exit events which I can then use to store off into a variable which node the mouse is over. When I get a drag started event from the group, I will know which child node to move around in relation to the drag event. I can then remove that node and replace it and still know which one to move around.
>
> Cheers
> Richard


-- 
Sebastian Rheinnecker
phone: +49 7071 9709050
fax: +49 7071 9709051

yWorks GmbH
Vor dem Kreuzberg 28
72070 Tuebingen
Germany
http://www.yworks.com
Managing Directors: Sebastian Müller, Michael Pfahler
Commercial Registry: Stuttgart, Germany, HRB 382340