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 conta
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
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 n
Hello,
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
th
The existing behavior does sound consistent at least. When a drag starts, the
node "captures" the mouse and doesn't let go until the event concludes. This is
the same as if the node had remained in the scene graph. Since the node is no
longer in the scene graph, there is no hierarchy to bubble /
