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

[Anthony Petrov]

Hi Sergey,

Thanks for the review.

On 12/14/2013 03:14 AM, Sergey Bylokhov wrote:
> Me surprises why fx calls this method several time.

It's all described in details at 
https://javafx-jira.kenai.com/browse/RT-34283
In a nutshell, we have to call acceptDrop() for the first time in order 
to retrieve the data from the DnD clipboard. However, the actual drop 
operation becomes known only after FX's event handler finishes its 
execution. Hence we have to call acceptDrop() another time to pass the 
final value to the AWT code before we call the dropComplete() method.

> 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.

> Probabbly acceptDrop should be
> noop in case of dropStatus  == STATUS_ACCEPT?

No. As I explained above, we do need to be able to redefine the drop 
operation. So this can't be a no-op.

> I guess the same change can be applied to the rejectDrop?

The current behavior of rejectDrop() doesn't cause any problems for FX. 
As long as there's no requests to allow this method to be called 
multiple times, I'd prefer to leave it as is. Should need arise, we can 
always revisit this later.

--
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
>
>