Re: [platform-swt-dev] MacOSX Cocoa Drag and Drop

[Duong Nguyen <duongn@xxxxxxxxxx>]

Hi Alex,

On most platforms, you need to register
the transfer type to the OS before it can be used. On Carbon, we are faking
it since there doesn't appear to be a way to register the transfer type
with the OS.  We're simply using the hash value for the id. However,
if you look at TextTransfer, we are using the platform specific ids (kScrapFlavorTypeText
and kScrapFlavorTypeUnicode).
 I don't know if there's anything similar on Cocoa.

At this point, I don't think it's possible
to change the type in TransferData to String -- we can't change the API.

My recommendation is that you use the
hash value of the string for the type ids. 

Duong

"Alex Blewitt" <alex.blewitt@xxxxxxxxx>
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx

03/21/2008 08:01 PM

Please respond to
"Eclipse Platform SWT component developers list."        <platform-swt-dev@xxxxxxxxxxx>

To	"Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
cc
Subject	[platform-swt-dev] MacOSX Cocoa Drag and Drop

I'm starting to get back to the drag-and-drop on the
Mac Cocoa port of
SWT, based off of the Carbon port of the same.

In implementing the Transfer subclasses, there's a method getTypeIds()
which provides a platform-dependent set of IDs that can be used (as
well as the getTypeNames()). However, on Cocoa, the pasteboard types
are referenced by name (e.g. "NSStringPboardType") rather than
ID.

I could implement some kind of hard-coded mapping between these
strings and IDs (e.g. store the set of strings in an array and then
use an index lookup) but I wondered whether the getTypeIds() was part
of the platform API and thus needed, or whether it could just be left
unimplemented.

http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/dnd/Transfer.html#getTypeIds()

Similarly, the TransferData has a 'type' field which is an int, used
for comparison to see whether the type is the same or not. It could
equally well be a String (although the comparison would take a few
characters before finding a failure - the NS prefix is on all of the
standard ones).

I see there's a hash function 'registerType' in the Carbon branch
which just gives a hash of the string; I could use that as well and
just hash the names.

Is there a preferred implementation that I can put together?

Alex
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev