Cocoa mail archive
Re: Resource Fork - is this a good use/the right thing to do?
FROM : Daniel DeCovnick
DATE : Wed Apr 23 18:41:42 2008
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_removed>
> Rogue Research www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
DATE : Wed Apr 23 18:41:42 2008
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_removed>
> Rogue Research www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
