PDA

View Full Version : A somewhat involved question about Pasteboards




mdeh
Nov 6, 2009, 06:51 AM
I know this is a very long question, but I have run up against a brick wall...and know that to someone doing this regularly, there is probably some key concept that will make it all come together.


I am trying to get my head around the concept of pasteboards...and am at the point of having read / reread the documentation many times, and am hoping for someone to tie some conceptual threads together. So, here goes.

My conceptual vision of them is that they are nothing more than "psuedo" dictionaries ..ie they hold objects for a supplied list of "keys" and the keys are called UTIs or pasteboard types. **IF** that is true, I am not sure how strong this relationship is ie does **each** object have a key...but I had better stop there as this may be completely incorrect.


Now....certain types know implicitly how to write themselves to a pasteboard, so one just uses those methods ( clearContents & writeObjects) to do so, after supplying the appropriate types first?

Now, when it comes to **custom** data, as it is called, I am getting a little lost/ more lost?

There is a section called "Custom Data" here:


http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PasteboardGuide106/Articles/pbCustom.html

So, it's my understanding that **if** you have a MyCustomClass, you need to tell Cocoa *How* to handle your ivars.


The example given is this.


@interface Bookmark : NSObject <NSCoding, NSPasteboardWriting, NSPasteboardReading> {
}
@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) NSString *notes;
@property (nonatomic, retain) NSDate *date;
@property (nonatomic, retain) NSURL *url;
@property (nonatomic, retain) NSColor *color;
@end


Implementing the protocols, this method makes sense to me.


- (NSArray *)writableTypesForPasteboard:(NSPasteboard *)pasteboard {
static NSArray *writableTypes = nil;

if (!writableTypes) {
writableTypes = [[NSArray alloc] initWithObjects:BOOKMARK_UTI,
(NSString *)kUTTypeURL, NSPasteboardTypeString, nil];
}
return writableTypes;
}




I *think* what it does is this. When the time comes to move data **to** the pasteboard, the pasteboard solicits the types "MyCustomClass" exposes?...if that is the correct term.

So, BOOKMARK_UTI is a user defined UTI, (NSString *)kUTTypeURL is a specific type identifying an URL...although I am not sure **why** it needs to be caste to an NSString.


So far, I think so good. But the one method that really has me stymied is this one , although I think I understand it somewhat.



- (id)pasteboardPropertyListForType:(NSString *)type {

if ([type isEqualToString:BOOKMARK_UTI]) {
return [NSKeyedArchiver archivedDataWithRootObject:self];
}

if ([type isEqualToString:(NSString *)kUTTypeURL]) {
return [url pasteboardPropertyListForType:(NSString *)kUTTypeURL];
}

if ([type isEqualToString:NSPasteboardTypeString]) {
return [NSString stringWithFormat:@"<a href=\"%@\">%@</a>",
[url absoluteString], title];
}

return nil;
}


Now, I understand that the order is important. But, what **exactly** is being sought here? Is the pasteboard saying to the class....
Here is a type ( the argument (NSString *) type. Please return to me an Object, in a way I can understand?
So, if the type is the **entire** bookmark (BOOKMARK_UTI), then archive it using the method NSKeyed... etc. If the type is a URL then do this....take the url.

If It's a string, then format it.


And lastly just some basic code.


**if** the return ( above) is just a "url", then why return [url pasteboardPropertyListForType:(NSString *)kUTTypeURL]...and not just "url".There is clearly something that I am missing here. And the **very** last confusion is the return for the NSPasteboardTypeString. The 2 ivars that seem to be returned are the "title" and "url". So, let's say I wanted to choose "notes" how would one differentiate...or is it a matter that, in this implementation, notes would never be chosen for a drag, and **if** there were more than one object for a given type, would I need to add a more specific way of differentiating those.


This has just been a **very** long detour from Hillegass, but hopefully worth it in the end. Thanks for your kind input in advance.