Leonid,
if target and source are in the same container then the answer is
yes, but i don't think there is any problem with it.
At least there is no visible side-effect and the corresponding
regression tests and JCK tests are not affected by this change.
If they are in different containers then no event will be delivered to
target until we actually drag there but it is
Ok because the enterEvent will be generated on the native layer and
there will be no need in artificially synthesizing it.
With best regards,
Alex
On 9/7/12 19:17, Leonid Romanov wrote:
Hi,
Suppose that we are actually outside the target when the drag starts. Do I
understand correctly that with your change we will get an extra
processExitMessage() call at the very beginning of the drag? Is it OK?
On Sep 7, 2012, at 6:27 PM, Alexander Zuev <[email protected]> wrote:
Hello,
please review my fix for CR 7171812: [macosx] Views keep scrolling back to
the drag position after DnD
The reason is that we are wrongly issuing an dragEntered event when we start
dragging where drag source and drop target is the same component. It is enough
to change the initialization of the insideTarget variable to safely prevent
that from happening.
Bug description is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171812
Webrev can be found here: http://cr.openjdk.java.net/~kizune/7171812/webrev.00
With best regards,
Alex
