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




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




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

N/A

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

I would be interested in hearing why Sun decided to not make the Transferable
object accessible. I wish it were.

create a sub class of DropTargetContext and use
its getTransferable() method.

One way to get around this is to store the Transferable 
object in a class that the DragGestureListener, 
DragSourceListener, and DropTargetListener can get to.  You 
have to be carefull to null that value out when the drag is 
complete so that there isn't confusion in subsequent 
operations.  You can use the DragSourceListener.dragDropEnd 
method to do this.
It would be nice if this data was available through the 
DropTargetDragEvent, though.

The 2 workarounds (WA) are not as desirable as the
requested change (although thanks very much for them)!
The subclass WA actually requires two extended classes,
an extension of DropTargetContext to supply the
transferable, and an extension of DropTarget to override
createDropTargetContext.
The "store transferable" requires a change to the model
so that it still works with multiple views. The model
should not have to hold onto such a temporary piece of
information relating to DnD!

It is very annoying, that a Java file list cannot be examinated about file types in dragOver. 
Please consider enhancing the interface. 

I agree - there are definitely times when you need access to the transferable object in order to control drag under 
feedback and to decide whether to accept or reject a drop.  Having access to the data flavor isn't enough.  Please 
enhance the interface.

Bad news for all of you: there is not really a workaround.
The idea of subclassing DropTargetContext is impossible because it has a constructor with
default access, so you cannot define a subclass. And you cannot define a new class in package
java.awt.dnd to access the protected method getTransferable() because the class loader will
throw a security exception. Also using reflection to access this method is not successfull because
when you call method getTransferData() on the returned transferable you end up with the
following exception: java.io.IOException: class java.awt.dnd.InvalidDnDOperationException:No drop current 
caught while getting Data

The second described workaround will not work if the DragSource is not accessible which is the
case if you want to perform DnD between the windows file explorer and your java application (which is the 
kind of operation that i need).

So now its your turn my friends at Sun. Give us the possibility to do our work.

Bug Id  4378091 is a duplicate of this one.  Votes from it 
should be transferred here.

It is located here: 
http://developer.java.sun.com/developer/bugParade/bugs/437
8091.html

Yeah this was a poor design decision at best.  It also seems 
that one cannot even get the DataFlavor, much less the 
actual Transferable.

The only way to get around this is to have the 
DragGestureListener save a reference to the Transferable 
that is being used to initiate the drag with startDrag().  Not a 
pretty picture.

It is a very reasonable request. The feature is very useful.

I happen to notice that today it is just about exactly four 
years since this bug was submitted. That's a little anniversary 
right there. It seems strange to me though, that this 
enhancement - which I in my naive thinking believe would 
consist of three lines of code and a littly copy&paste in the 
documentation -, would take more than four years to perform.
It seems clear that there is a need for this feature. I can tell 
this by the number of votes in the various, identical bug 
reports, of which more than one are still open, and by the 
fury and desperation that can be sensed in the above posts - 
as well as in this one.

By the way, what exactly does "further investigation" mean? 
Is this feature that we so deeply crave something that could 
damage existing code, or provide weird behaviour? I think not.

But please, if I am wrong, let me know, and my agony as to 
why this is taking such a long time, may be somewhat 
oppressed.