On Oct 1, 2008, at 3:09 PM, Jim Correia wrote:
On Oct 1, 2008, at 5:27 PM, Nathan Vander Wilt wrote:

I am initiating a promise drag by adding an array of strings to my pasteboard using for the NSFilesPromisePboardType. The documentation states that "the types can be specified as filename extensions or as HFS file types encoded [as strings]". Is there any reason to not build an array of UTIs instead?

I don't believe that works. I thought I filed a bug about it, but cannot quickly locate it.

If you find definitively one way or the other, I'd appreciate your discovery. (It would require special support in the pasteboard for translation because legacy clients would only expect the extension or HFS type. Even just the extension is problematic for Carbon clients.)

Thanks for the advice, I've taken the liberty of posting back to the list as well.

I haven't experimented a ton, as the Finder and iPhoto both seem to accept (at least initially, in the case of iPhoto) any promise drag regardless of what I stuff into the array, and I hadn't many ideas of other programs to try it on. Despite Postel's principle, I'm tempted to use UTIs anyway, at least until we get bug reports of our app not playing nicely with another.

HFS types seem to be well deprecated in nearly every other area, the drag destination guides don't encourage checking the types anyway, and the API itself doesn't facilitate easy checking especially given the fact that strings already are *either* extensions or legacy type codes with no programmatic distinction. Plus who really wants to keep comparing strings (eg 'txt' vs. 'TXT' vs. 'TEXT' times every other supported format) when they could be using UTTypeConformsTo instead? :-)

thanks,
-natevw
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to