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