Review request for 7124262: [macosx] Drag events go to a wrong child. (original) (raw)
Alexander Zuev alexander.zuev at oracle.com
Thu Feb 23 22:45:42 PST 2012
- Previous message: Review request for 7124262: [macosx] Drag events go to a wrong child.
- Next message: Review request for 7124262: [macosx] Drag events go to a wrong child.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/viewbug.do?bugid=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
- Previous message: Review request for 7124262: [macosx] Drag events go to a wrong child.
- Next message: Review request for 7124262: [macosx] Drag events go to a wrong child.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]