Re: how to receive a Cocoa drag in a Carbon app using regular Drag Manager?
Re: how to receive a Cocoa drag in a Carbon app using regular Drag Manager?
- Subject: Re: how to receive a Cocoa drag in a Carbon app using regular Drag Manager?
- From: Daniel Morrow <email@hidden>
- Date: Wed, 13 Oct 2004 15:43:48 -0400
OK,
this is the last bit, and then I'll stop bothering everyone with this.
I have added a Uniform Type Identifier definition to my .plist, and it
still doesn't work. There's that cryptic bit about "make sure it is
read by the system" which I'm not sure is happening.
So, is there an actual sample .plist file which does this? If so, I'd
like to see it. Tracking down this stuff is difficult.
but here's my definition:
<key>UTExportedTypeDeclarations</key>
<array>
<dict>
<key>UTTypeIdentifier</key>
<string>com.maned.QuickLink</string>
<key>UTTypeDescription</key>
<string>Quicklink data</string>
<key>UTTypeConformsTo</key>
<array>
<string>public.data</string>
</array>
<key>UTTypeTagSpecification</key>
<dict>
<key>com.apple.nspboard-type</key>
<string>QuickLink</string>
<key>com.apple.ostype</key>
<string>ABCD</string>
</dict>
</dict>
</array>
The name of my app is "QuickLink" so, in my Cocoa app, I'm just using
"QuickLink" as the type.
The UTTypeTag keys were found by running my app, assigning a string to,
say, kUTTagClassOSType, and then doing a "Show Description" in Xcode's
debugger to see what the actual values were. This is weird, because the
key name "com.apple.ostype" differs from what is shown in "UTTypes.h"
example. Which makes me suspicious that maybe I'm not using the right
keys.
So, to conclude, I still can't get this to work, although it appears
that I'm doing everything right. I guess I'll go ahead and use the
"GetDragPasteboard" call, even though this will be difficult seeing as
the plugin is CFM and pointing to the Universal Headers found in
Metrowerks. I know how to point MW to look at the other headers, but
this just adds extra complexity I was hoping to avoid.
If there are no further comments on this, I'd like to thank everyone
who was so helpful.
-Dan.
On Oct 13, 2004, at 2:13 PM, Bryan Prusha wrote:
Ah, I see. Yes, if you add a Uniform Type Identifier definition
(UTType.h) to your .plist and make sure it is read by the system this
will work. Make sure it describes both an NSPasteboardType and it's
corresponding OSType. Again though, this will only work on 10.3 and
later because this type of synonym conversion didn't exist until Drag
Manager was reimplemented on top of the Carbon Pasteboard. Given your
plug-in restrictions this makes sense. In the longer run I highly
recommend adopting the Carbon Pasteboard.
On Oct 13, 2004, at 10:48 AM, Daniel Morrow wrote:
OK,
I got another response suggesting that I use "GetDragPasteboard" too.
But here's my situation - I'm a plugin in InDesign, which, (from what
I can tell) does not use the Pasteboard APIs. The InDesign APIs has
nice wrapper classes which handle drag-n-drop. These routines are
cross-platform (Mac & PC). So, I'm trying to avoid using Mac-specific
code in here, if at all possible. On the Mac, they seem to wrap the
Drag Manager, because their APIs ask for drag-flavors (4-char codes)
to get the dragged data.
So, what I'd like, ideally, to do is say to the OS:
"Hey OS, if you get anything on the pasteboard with type
"MySpecialType" it also has a Drag-flavor 'MySp'."
I thought this might be possible by adding some kind of data into my
plist which would describe this translation, and then whenever I
dragged my custom data from my app, it would also be dragging along a
drag-flavor of "MySp"
The reason I'm using a custom type in the first place is because my
plugin (in InDesign) doesn't want to intercept all 'TEXT' drops, or
any other standard type. This is a special drop, with my special
data, created by my app.
if this is truly not possible, then I'll move on to using
GetDragPasteboard.
Again, thanks for all the help,
-Dan.
On Oct 13, 2004, at 12:57 PM, Bryan Prusha wrote:
This is one of the big reasons the Carbon Pasteboard was
introduced in 10.3 (Pasteboard.h). It's flavors are based on
Uniform Type Identifiers which can contain information about both
NSPasteboard types as well as their corresponding four character
codes. What you want to do is add the data on the Cocoa side as you
already do and adopt the Carbon Pasteboard on the receiver side.
The Pasteboard can be retrieved from the drag via GetDragPasteboard.
From there you can use UTTypeCreatePreferredIdentifierForTag to
create a dynamic UTI (UTType.h) from the NSPasteboard type you used
earlier. Make a request of that dynamic UTI flavor from the
pasteboard and you'll receive the data. Unless you're using one of
a handful of well known types there is no way to receive Cocoa
pasteboard data using Drag Manager. Adopting the Carbon Pasteboard
is the only way to do this in a general manner. Since you're
already familiar with Drag Manager learning the Carbon Pasteboard
will be very straight forward.
Please check out the PasteboardPeeker sample code for
examples of all things Pasteboard (copy&paste, drag&drop, services,
translations).
http://developer.apple.com/samplecode/PasteboardPeeker/
PasteboardPeeker.html
On Oct 13, 2004, at 7:22 AM, Daniel Morrow wrote:
I assume there's a technote about this somewhere, but I'm having
trouble finding it.
I have two apps. One is a Cocoa app which contains a table view,
and I want to drag items from that table to another app. Dragging
them out in Cocoa is pretty easy.
The other app is Adobe InDesign. It appears that InDesign is using
regular Drag manager calls. I'm writing an InDesign plugin.
InDesign gives me a way to get the DragReference. Which appears
valid.
I ask it how many items are in the dragref. It tells me 1, so far,
so good. Next I get the DragItemRef, and it oddly always has the
address "0x000C0C0A". Which is amusing. But I really need to get
the data out of it.
Is there a way to do this? I can change the code in the Cocoa app,
which I'm writing. But I have to use a DragReference on the
InDesign side. Any ideas?
-Dan.
P.S. - Sorry to post this to two lists, but I guess there aren't
too many people working in both worlds simultaneously like this.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden