Question

The documentation for NSPasteboard‘s -types reads:

Return Value

An array of NSString objects
containing the union of the types of
data declared for all the pasteboard
items on the receiver. The returned
types are listed in the order they
were declared.

Despite this, I have an NSPasteboard with only one NSPasteboardItem and [pboard types] returns more types than [item types] returns. Can anyone explain this?

Code

Here’s some code that evidences the problem:

- (BOOL)performDragOperation:(id <NSDraggingInfo>)sender {
    NSPasteboard *pboard = [sender draggingPasteboard];

    // Prove that there's only one item
    if ([[pboard pasteboardItems] count] > 1)
        return NO;

    for (NSString* type in [pboard types])
        NSLog(@"Pasteboard type: %@", type);

    NSPasteboardItem* item = [[pboard pasteboardItems] objectAtIndex:0];

    for (NSString* type in [item types])
        NSLog(@"Item type: %@", type);

    return NO; // Ignore for example
}

Output

When I drag a link from Safari I get the following output:

Pasteboard type: dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
Pasteboard type: WebURLsWithTitlesPboardType
Pasteboard type: dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
Pasteboard type: Apple URL pasteboard type
Pasteboard type: public.url
Pasteboard type: CorePasteboardFlavorType 0x75726C20
Pasteboard type: public.url-name
Pasteboard type: CorePasteboardFlavorType 0x75726C6E
Pasteboard type: public.utf8-plain-text
Pasteboard type: NSStringPboardType
Item type: dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
Item type: dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
Item type: public.url
Item type: public.url-name
Item type: public.utf8-plain-text

Wild Speculation

It looks like [item types] is basically showing the same types as [pboard types], but only the UTI versions. And since [pboard types] seems to be interleaving the UTI types with the corresponding other type (?) of types, it’s basically a mapping…

I could probably ignore this issue by simply using the UTI for the data format I want, but I’m looking for WebURLsWithTitlesPboardType (corresponding to dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k), and I’m wary of those dyn.(...) UTIs. Sounds like something that shouldn’t be hardcoded.

Is there a reliable way of transforming WebURLsWithTitlesPboardType-style identifiers into UTIs? I don’t trust the approach of actually using [pboard types] as a mapping…

Answer 1

I’m convinced that documentation for NSPasteboard‘s -types is actually faulty. The correct documentation should be something like:

An array of NSString objects containing the union of the types of data declared for all the pasteboard items on the receiver, with the addition of old-style, non-UTI type identifiers.

If you’re targeting OS X 10.6+, you should be able to completely disregard NSPasteboard‘s -types and focus only on each NSPasteboardItem‘s -types, but this requires working exclusively with UTIs.

To convert a non-UTI type identifier to a UTI you need to use the UTTypeCreatePreferredIdentifierForTag() function; you also need to know what kind of identifier you already have (kUTTagClassFilenameExtension, kUTTagClassMIMEType, kUTTagClassNSPboardType or kUTTagClassOSType). This type is the first argument to the function. The second is the identifier itself (as a CFStringRef). While the documentation suggests that it’s OK to pass NULL for the third argument, it seems to be important to actually pass kUTTypeData when generating these dynamic UTIs.

For example, to get the (dynamic) UTI for data with the old-style identifier “WebURLsWithTitlesPboardType”:

CFStringRef webURLsWithTitlesUTI = UTTypeCreatePreferredIdentifierForTag(kUTTagClassNSPboardType, CFSTR("WebURLsWithTitlesPboardType"), kUTTypeData);