No events when drag target is removed from the scenegraph while dragging
Sebastian Rheinnecker
sebastian.rheinnecker at yworks.com
Mon Aug 19 07:31:56 PDT 2013
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
More information about the openjfx-dev
mailing list