JDK-4248542 : DropTargetListener can't access the transferable in dragOver and dragEnter
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.2.1,1.2.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-06-22
  • Updated: 2003-08-08
  • Resolved: 2003-08-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Relates :  
Relates :  
Description

Name: vi73552			Date: 06/22/99


It is impossible for a DropTargetListener to examine the transferable for accepting or rejecting the drag operation if it necessary to do more controls than just looking to DataFlavor.
The DropTargetDragEvent doesn't have access to the transferable and in DropTargetContext method getTransferable() has protected access.
----------------------------------

Hello,

my problem is to implements a drag and drop in a tree in witch I don't want
to allow the drop of a parent in a child.

To check if drop is possible I used the dragOver() method of the
DropTargetListener, like this I can see if the drag is over a container
node or over a leaf. But even if I allow the drop it can occure that I
raised an error dialog because the drop was in fact not allowed
(just like the windows file explorer).

I think that this point is not specific to my problem and in dnd operation
it could be useful in certain condition to check the data transfered just
like in copy-paste it is possible to get the clipboard content.

regards.
Eric.


(Review ID: 84647) 
======================================================================

Name: krT82822			Date: 11/07/99


Classic VM (build JDK-1.2.2-W, native threads, symcjit)

For DropTargetDragEvent events, it would be useful to access the
transferable data somehow.  Currently, for this event access to the data is
protected via
 
       DropTargetContext context = event.getDropTargetContext();
       
       BUT
            context.getTransferable() is protected.

The reason I would like this feature is that I am working on drawing graphics.
As the mouse moves, my application would like to draw a "label" indicating
what is being dragged.  This is done by drawing a rectangle with text.  The
text comes from the transferable data.

In my source window, I can get to the tranferable string which I use to
form my "label", but in my target window, I do not see how this information
is accessible.  I may have many different target windows, so it is not
practical to make one big class in order to have access to this data.
(Review ID: 97221)
======================================================================

Name: krT82822			Date: 12/11/99


The feature request applies to all versions!

Access to the Transferable Data in a Drag Drop operation can only be obtained
from a Drop event.  It is IMPORTANT that the developer can access the
Transferable Data BEFORE a drop operation occurs.

It is ESSENTIAL that the Transferable can be obtained from the dragEnter
(DropTargetDragEvent dtde) method so that the Java application can compute the
drop area and provide the user with VISUAL feedback of the pasted area.

The transferable data is needed because the application may have to PARSE the
data to calculate the drop bounds.  The Visual feedback is ESSENTIAL to
indicate (for example) populated table cells which will be overwritten when the
drop is performed.
(Review ID: 98838)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15
14-06-2004

EVALUATION We will consider this update for Merlin. It seems reasonsable but requires further investigation. roger.brinkley@Eng 2000-02-23
23-02-2000