And still looks good to me. With best regards. Petr.
On 17.12.2013, at 18:31, Sergey Bylokhov <[email protected]> wrote: > Hi, Anthony. > The fix looks good. > > On 17.12.2013 16:59, Anthony Petrov wrote: >> Hi Sergey, >> >> Good point. You're right, it's just impossible to happen. So here's an >> updated webrev: >> >> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.2/ >> >> -- >> best regards, >> Anthony >> >> On 12/17/2013 03:07 PM, Sergey Bylokhov wrote: >>> Hi, Anthony. >>> On 12/16/13 6:19 PM, Anthony Petrov wrote: >>>>> Is it necessary to check !dropComplete? >>>> >>>> Well, I wanted to add this case to my regression test, but it appears >>>> that the DropTargetContextPeer gets destroyed after user's code calls >>>> dropComplete(), and so this check is never performed actually. >>>> However, I'd like to keep it in place because it just doesn't make any >>>> sense to call acceptDrop() after the drop is complete. It looks safe >>>> to me. >>> It will be strange to have dropStatus= ACCEPT and drop status complete >>> at the same moment, No? >>>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> >>>>> On 13.12.2013 20:53, Anthony Petrov wrote: >>>>>> Hi Petr, Sergey, >>>>>> >>>>>> Please review a fix for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8029979 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-3-acceptDrop-8029979.0/ >>>>>> >>>>>> I enable calling SunDropTargetContextPeer.acceptDrop() as many times >>>>>> as needed, for as long as the DnD operation isn't complete yet. >>>>>> Running open and closed DnD regression tests revealed no new failures. >>>>>> >>>>>> Note that later we will need to back-port this fix to 8u20. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>>>> >>> >>> > > > -- > Best regards, Sergey. >
