Is there a way to unfilter an NSPasteboard for what the source application specifically declared it would provide?
I'm attempting to serialize pasteboard data in my application. When another application places an RTF file on a pasteboard and then I ask for the available types, I get eleven different flavors of said RTF, everything from the original RTF to plain strings to dyn.* values.
Saving off all that data into a plist or raw data on disk isn't usually a problem as it's pretty small, but when an image of any considerable size is placed on the pasteboard, the resulting output can be tens of times larger than the source data (with multiple flavors of TIFF and PICT data being made available via filtering).
I'd like to just be able to save off what the original app made available if possible.
John, you are far more observant than myself or the gentleman I work with who's been doing Mac programming since dinosaurs roamed the earth. Neither of us ever noticed the text you highlighted... and I've not a clue why. Starting too long at the problem, apparently.
And while I accepted your answer as the correct answer, it doesn't exactly answer my original question. What I was looking for was a way to identify flavors that can become other flavors simply by placing them on the pasteboard AND to know which of these types were originally offered by the provider. While walking the types list will get me the preferred order for the application that provided them, it won't tell me which ones I can safely ignore as they'll be recreated when I refill the pasteboard later.
I've come to the conclusion that there isn't a "good" way to do this. [NSPasteboard declaredTypesFromOwner] would be fabulous, but it doesn't exist.
-[NSPasteboard types] will return all the available types for the data on the clipboard, but it should return them "in the order they were declared."
The documentation for -[NSPasteboard declareTypes:owner:] says that "the types should be ordered according to the preference of the source application."
A properly implemented pasteboard owner should, therefore, declare the richest representation of the content (probably the original content) as the first type; so a reasonable single representation should be:
[pb dataForType:[[pb types] objectAtIndex:0]]
You may be able to get some use out of +[NSPasteboard typesFilterableTo:]. I'm picturing a snippet like this:
NSArray *allTypes = [pb types];
NSAssert([allTypes count] > 0, #"expected at least one type");
// We always require the first declared type, as a starting point.
NSMutableSet *requiredTypes = [NSMutableSet setWithObject:[allTypes objectAtIndex:0]];
for (NSUInteger index = 1; index < [allTypes count]; index++) {
NSString *aType = [allTypes objectAtIndex:index];
NSSet *filtersFrom = [NSSet setWithArray:[NSPasteboard typesFilterableTo:aType]];
// If this type can't be re-created with a filter we already use, add it to the
// set of required types.
if (![requiredTypes intersectsSet:filtersFrom])
[requiredTypes addObject:aType];
}
I'm not sure how effective this would be at picking good types, however.
Related
I'm working with iTunes via AppleScript. The artwork element of a track contains image data (or raw data, which appears in practice to return the same thing), which can be retrieved and, say, directly written to a file. (It's an e.g. PNG bytestream.)
But I don't know how to do anything with this thing besides write it to a file. I'd like to ask it how many bytes it contains, or even rummage through it (though the latter may well be out of scope for AppleScript). In Script Debugger, it looks like «data tdtaXXXXXX.....» (hex values where I wrote the XXXs), and the iTunes scripting dictionary doesn't link through to any useful type/class for it.
I'm not really sure what the guillemets mean in AppleScript, or what the nature of this object is, or whether this thing can be interrogated natively. Any references on this would be helpful. Thanks!
See https://books.google.com/books?id=rW5k0w_wC3MC&pg=PA57&lpg=PA57&dq=guillemets+applescript+events+data&source=bl&ots=ogzi9W4jxW&sig=7ct-n0wpzdhBhtHDJtTrZDKgEEk&hl=en&sa=X&ei=-qSYVICZAsjooASo0oKwCg&ved=0CB4Q6AEwAA#v=onepage&q=guillemets%20applescript%20events%20data&f=false for explanation of raw codes and data and use of guillemets in AppleScript; See this answer:
Getting artwork from current track in Applescript
for an example of writing image data from iTunes artwork to file.
I have an object containing various NSString objects and variables which I us NSCoding to archive to a file on the disk and later unarchive. So far everything has been working perfectly.
Today, I wanted to add an NSMutableArray to the object and tried to encode using the:
[encoder encodeObject:myArray ForKey:#"myArray"];
and later decode it using:
[self setMyArray:[decoder decodeObjectForKey:#"myArray"]];
It doesn't appear to be working, and while I don't get any errors in the encoding or decoding itself, I do get an error if I try to modify the value of the array after decoding from the file.
I'm sure I'm doing something completely wrong here, but not entirely certain what. I'm thinking perhaps it may have something to do with it not properly allocing during the unarchive.
Anything look blatantly obvious as the source of the problem?
It doesn't appear to be working, and while I don't get any errors in
the encoding or decoding itself, I do get an error if I try to modify
the value of the array after decoding from the file.
Decoding an archive gives you immutable objects regardless of whether they were mutable or immutable when you encoded them. You're not doing anything particularly wrong -- it's working as advertised.
See this answer for another example of a similar problem, and a solution:
[self setMyArray:[[decoder decodeObjectForKey:#"myArray"] mutableCopy];
I have a bunch of data (data that will remain constant) that I want to import in to my Cocoa app (OS X, iOS). This data is a pairing of "Title" and "Body" where the title might be "Really Cool Stuff" and body will be "Gosh, there's a lot of really cool stuff. Here's a big list...". There are several of these pairs, in an ordered list.
One data type that comes to mind is to create a aggregate object type with NSString *title; and NSString *body; properties, and then have an array of these. Is there another way such as an ordered dictionary.. (where title is a unique key in to dictionary of body)?
Last piece of the puzzle - I want this data to be in a persistent data store of some sort, the more automatic the better. Ideally, I want to use Core Data. So an answer that addresses this in terms of Core Data is preferred. To complicate things, the data is being spit out of a perl script (would be tricky to rewrite in Objective-C/C)
You can design it based off of NSString as you alluded to. You'd then be able to insert the whole object into Core Data at some point in your program. In your Core Data design, you could just have one block containing the two attributes of the object.
First post - hope I'm doing it right!
I have a file, lexicon.plist, containing an array of about 250K words. I want to load all words of length 'n' into an NSArray.
I know about the NSArray instance method:
(id)initWithContentsOfFile:(NSString *)aPath
but I don't see any way to intervene in the process of reading the file into the NSArray. The only solution I can see is to first load the entire lexicon into one NSArray, and then run through it in a loop selecting the elements of length 'n'.
I'm very new at Cocoa, but I have come across some methods that perform some sort of iterative task, that accept a "block" of code that is invoked at each iteration. I was wondering if such a functional variant of initWithContentsOfFile might exist, or how else I might iteratively read an array from a .plist file and filter the elements I'm interested in.
[And if you're wondering if this might be a case of premature optimization - it is ;-) But I'd still like to know.]
.plist files are basically XML files so you can use an NSXMLParser on it and filter out the elements of interest.
If you want to load a filtered selection of a saved data, you should use a SQL repository using SQLite, for example.
Plain files can only be fully loaded in memory.
Is it possible to have an NSdictionary where the keys are NSDates and also have it writeable/archiveable to disk?
Not using property lists, as only string keys are allowed there. You should be able to write it using NSKeyedArchiver, but that has the disadvantage of being a more opaque format. Alternatively, you could of course make a copy of the dictionary where you convert the dates to strings.
Yes, this should work just fine - and NSDate elements are also suitable for plist encoding. Might depend on the value you put in as values, though.
If you experience problems, please update your question with code.