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