[news.eclipse.platform.swt] Re: Dropping Java objects as text

[David Huebel <davidhuebel@xxxxxxxxxxx>]

isSupportedType is the only way (in platform-neutral code, don't know about
native stuff) of figuring out what kind of transfer the target is
requesting.  ByteArrayTransfer is abstract, but my ByteArrayTransfer
subclass doesn't override isSupportedType, and there's no point in doing so
unless I create my own TransferData subclass.  So, for distinguishing
requested drop types, I'm stuck with ByteArrayTransfer's default behavior
unless I subclass TransferData.  Am I right so far?

Having now written enough to clarify my thinking, I think my question is,
will TextTransfer.isSupportedType and ByteArrayTransfer.isSupportedType
ever return true for the same TransferData instance, or are they guaranteed
to be mutually exclusive on every platform?  If they're mutually exclusive,
then I can use them to distinguish between the two cases (an internal drop
and an external drop.)  Otherwise I have to come up with some other
solution involving platform-specific code, such as implementing my own
TransferData subclass.

Again, thanks for the replies; this conversation is helping clarify my
thinking.

-David 

Duong Nguyen wrote:

> ByteArrayTransfer is an abstract class. You don't use ByteArrayTransfer
> directly. It just provides some native implementation to allow you to
> transfer bytes to another application (after you have serialized your
> objects into bytes). Each transfer type has a unique id and each id is
> unique to the platform that you're on. When the bytes are transferred, the
> header will include the unique transfer type id so that the target can
> identify it.
> 
> If an target application says that it supports "TextTransfer" then the
> source can safely give it a String. If the target application requests
> that it can only support TextTransfer then the source must only give it
> text and nothing else.
> 
> In your case, you don't need to create a new transfer type if all you want
> to do is transfer text (in addition to your existing transfer type). You
> can continue to use your current transfer type to drag your object to your
> own application and add the text transfer so that other applications can
> read it. Just set the transfer types to be your transfer type and the
> TextTransfer. Eg.
> 
> dragSource.setTransfer(new Transfer[] {MyInternalTransfer.getInstance(),
> TextTransfer.getInstance()});
> 
> I assume you already have a "MyInternalTransfer" since it's already
> working for you. Next, you need to ensure that if the target can support
> the transfer type that you're providing. "MyInternalTransfer" will only be
> requested if the target is your own application since no other app knows
> about it. If the target app (such as NotePad) says that it can only
> support text then you must only give it the String representation of your
> object.
> 
> public void dragSetData(DragSourceEvent event) {
> if (MyInternalTransfer.getInstance().isSupportedType(event.dataType)) {
> event.data = myObject; // do your current transfer magic for your
> object. This is just an example.
> }
> if (TextTransfer.getInstance().isSupportedType(event.dataType)) {
> event.data = myObject.toString();
> }
> }
> 
> Note that TextTransfer will work with any native application (eg. WordPad,
> NotePad on Windows) that accepts text. It'll work on all platforms.
> 
> Please see Snippet185 for a complete example, as it shows you how to drag
> an object (a file). The target side can choose to accept the object as a
> String using TextTransfer or it can accept the object as an File using
> FileTransfer. If you drag the object in this example to NotePad, a string
> will be transferred. If you drag the object in this example to
> FileExplorer, you'll get a File transfer. If you drag the object in this
> example to itself, you can get either.
> 
> If both sides (dragSource and dropTarget) can agree on at least one common
> transfer type then the drag and drop is allowed.
> 
> You should implement your drag and drop the same way as Snippet185. No new
> Transfer (other than what you've already implemented) type is necessary.
> No native calls are required.
> 
> Duong
> 
> David Huebel wrote:
> 
>> Thanks for the reply.  The reason I'm confused is that I don't know how
>> to
>> reliably distinguish between the two cases in dragSetData.  I don't want
>> to create my own TransferData implementation (since that would require
>> learning native drag-and-drop implementation details on every target
>> platform) so my ByteArrayTransfer subclass acts just like
>> ByteArrayTransfer with respect to TransferData instances.
> 
>> I have no idea (and the documentation gives no hint) whether
>> TextTransfer.isSupportedType will reliably return false for the
>> TransferData offered by a ByteArrayTransfer -- and the code here is
>> platform-dependent.  Do native drag-and-drop implementations consider
>> byte
>> arrays and strings to be completely incompatible?  I don't even know the
>> answer to that on my *own* preferred platform.  So I'd like to set the
>> same data regardless and let Eclipse pick the Transfer instance using
>> whatever native voodoo it uses for that....
> 
>> I guess I should create my own TransferData class so I could rely on
>> isSupportedType to distinguish between the two cases, but writing
>> platform-specific code seems pretty onerous for a simple drag-and-drop
>> task.
> 
>> -David