// 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.
OTOH, ResTypes are simpler to use and more efficient than strings of
arbitrary length. I just don't know that the demand for resource
support will ever be large enough to need the infinite set of reverse-
DNS namespace of UTIs.
Larry
_______________________________________________
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
