Looks good to me.
Thanks,
Alexander.
On 21/07/2017 04:02, Sergey Bylokhov wrote:
Hello.
We got a response from the previous maintainer of this code, that it
was implemented long time ago, and works probably because of a
different class hierarchy. Currently the code works in this way:
[super respondsToSelector:@selector(draggingEntered:)]
"It goes to the superclass, gets the implementation of
respondsToSelector: there, and then runs it on the current object,
which will return YES. But when we call [super draggingEntered] it
will crash because there are no such methods in NSView".
Since the code does not work I suggest to drop it.
Bug: https://bugs.openjdk.java.net/browse/JDK-8139050
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8139050/webrev.01
The new test was added(it is modified version of test submitted by the
users of Swing).
Note that both tests still fails because of another bug:
https://bugs.openjdk.java.net/browse/JDK-8153871
I just reopened it and will start to work on it after this one.
On 10.11.2015 4:53, Alexander Scherbatiy wrote:
The following changes have been contributed during JDK Mac OS X port
developing:
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/9023fa7e47c9
src/macosx/native/sun/awt/AWTView.m
---------------------
+ if (dropTarget != nil)
+ dragOp = [dropTarget draggingEntered:sender];
+ else if ([super respondsToSelector:@selector(draggingEntered:)])
+ dragOp = [super draggingEntered:sender];
---------------------
May be you could know why it was necessary to check dragging*
selectors in super class when the super class is NSView which does
not define them.