Re: Resource Fork - is this a good use/the right thing to do?
Re: Resource Fork - is this a good use/the right thing to do?
- Subject: Re: Resource Fork - is this a good use/the right thing to do?
- From: Daniel DeCovnick <email@hidden>
- Date: Wed, 23 Apr 2008 12:41:42 -0400
That the Resource Manager is still around in 64-bit definitely
alleviates one of my concerns - "will whatever I use still be around
in the future?"
Thanks much,
Dan
On Apr 23, 2008, at 10:12 AM, Sean McBride wrote:
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@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden