<AWT Dev> [9] Review request for 8029979: Allow multiple calls to DropTargetDropEvent.acceptDrop()

[Petr Pchelko]

And still looks good to me.

With best regards. Petr.

On 17.12.2013, at 18:31, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> 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.
>