Review request for 7124262: [macosx] Drag events go to a wrong child.
Alexander Potochkin
Alexander.Potochkin at oracle.com
Mon Feb 27 03:39:25 PST 2012
Hello Alexander
In LWComponentPeer.removeDropTarget() you calladdDropTarget()
this looks like copy-paste error
it would also be great to give some more details about the unexpected
conversion in CDropTarget class
Thanks
alexp
> On 2/22/12 20:13, Sergey Bylokhov wrote:
>> 22.02.2012 21:51, Alexander Zuev wrote:
>>> Hello,
>>>
>>> please review my fix for bug 7124262: [macosx] Drag events go to a
>>> wrong child.
>>>
>>> Bug description is
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124262
>>>
>>> Webrev can be found here:
>>> http://cr.openjdk.java.net/~kizune/7124262/webrev.00/
>> I guess that old method code can be moved to LWWindowPeer?
> I'm not sure about it - the fact that i can' figure out the situation
> where we should register
> drag recognizer and component is not in the hierarchy where root
> component has the LWWindowPeer derived
> peer doesn't mean that this situation is impossible. So i would let
> this code be there.
>
>> What about removeDropTarget()?
> Yep - good catch - forgot that method.
>> Why we need this import?
>> import java.awt.peer.WindowPeer;
> Artifact of the debugging. Removed.
>> !winPeer.equals(this) could be replaced with !=?
> In this case - yes. Fixed.
>
> The new version of webrev available at
> http://cr.openjdk.java.net/~kizune/7124262/webrev.01/
>
> With best regards,
> Alexander Zuev
>>>
>>> We are incorrectly registering DropTarget listener in the
>>> LWComponentPeer even if peer is not the LWWindowPeer
>>> and because of that we are overriding the listener created for the
>>> window itself so all the events come to the last added
>>> AWT component.
>>>
>>> With best regards,
>>> Alexander Zuev
>>
>>
>
More information about the macosx-port-dev
mailing list