// Added resources are automatically committed on close.
Presuming that some data was to be stored in my application's
writable resource file, I could omit the FSRef and fork parameters.
Frankly, this is not a sensible use of Carbon events. Events are
meant to communicate that something has happened. They're not a
long-term data storage mechanism.
If we wanted to do something like this, the right API would be one
that let you attach your dictionary directly to the window:
SetWindowPersistentInfo( window, dictionary ), or something like
that. A Carbon event is not an appropriate solution.
Not only that, but why are we talking about 32-bit OSTypes? Why limit
ourselves to the namespace of OSTypes when we have the infinite
reverse-DNS namespace of UTIs to work with? :) One of the limitations
of the resource manager is unless you already knew every type of
resource, it wasn't always clear at a glance what a ResType identified.
-- Gwynne, daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden