Hi, Alexander.
Can you please clarify why this event flushing is necessary.
As far as I understand we have this sequence of calls:
performDragOperation:
-> handleDropMessage
-> postDropTargetEvent(....,DISPATCH_SYNC)
-> postEvent to EDT
-> block Appkit untill event is not dispatched
-> unlock appkit and returns to performDragOperation:
-> then do the same steps as previous two in flushEvents()
() post+block+unlock
Probably it was necessary before JDK-8006634 was implemented?
On 07.10.15 16:25, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8136999
webrev: http://cr.openjdk.java.net/~alexsch/8136999/webrev.00
The test sets drop target to null in the drop handling which leads to
the drop target resources disposing.
The fix moves events flushing to the
CDropTargetContextPeer.handleDropMessage() method.
Thanks,
Alexandr.
--
Best regards, Sergey.
