Re: how to receive a Cocoa drag in a Carbon app using regular Drag Manager?

FROM : Daniel Morrow
DATE : Wed Oct 13 21:46:38 2004

Nevermind!

Finally, it started to work.

Don't know what magic incantation of logging off, and changing the 
.plist file did the trick, but it finally worked!

Thanks again!

-Dan.

On Oct 13, 2004, at 3:43 PM, Daniel Morrow wrote:

> 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_removed>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/carbon-dev/
>>>>> <email_removed>
>>>>>
>>>>> This email sent to <email_removed>

>>>>
>>>>

>>>

>>
>>

>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Carbon-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/carbon-dev/<email_removed>
>
> This email sent to <email_removed>
>