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
