On 4/23/08 1:21 AM, Daniel DeCovnick said: >I'm writing an application that opens particular kinds of files, >parses them, displays an editable graphical representation of the >contents of a file, and saves the results of the changes to the file. >However, some graphical changes don't result in changes to the >original file, yet those changes need to be saved - a little bit >analogous to the Finder saving the positions of icons in a window, but >not changing the files themselves. This seems like a perfect use of >package documents (a la .rtfd), except for one problem: the files I'm >opening aren't mine, and should remain openable in other applications, >so I can't wrap them up. I'd also really like to avoid making changes >to the files themselves, at least the portions that their normal >programs read.
The Resource fork has been used for a long time for exactly that purpose. As others have said, extended attributes are another possibility. Both risk being clobbered by poorly written tools. Personally, I think a resource is a better idea. They're actually less likely to get clobbered as they have been around longer (you could even copy them to a Classic system, or 10.0, etc.). The Resource Manager is not deprecated and is even available in 64 bit (unlike other parts of Carbon). NDResourceFork provides a nice Cocoa wrapper over the C APIs. See: <http://homepage.mac.com/nathan_day/pages/source.xml> -- ____________________________________________________________ Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
