Well, that jira entry was closed fast.
Am 19.08.2013 15:00, schrieb 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
