Say I have a text document with some associated particulars like
window size, marks, selection, etc. that I'd like to have stored
in the file's resource fork. I keep the marks in a
CFDictionaryRef. I would concoct an event something like:
// 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.
Then I'm redefining the meaning of Carbon events and keeping all
you Apple engineers gainfully employed for years to come.
What you're suggesting is that they muddy the waters.
GetApplicationEventTarget(), GetWindowEventTarget(), and
GetControlEventTarget() exist today. I don't see any difference if
there was to be a GetResourceManagerEventTarget(),
GetFileManagerEventTarget(), or a GetNavManagerEventTarget(). I see
usefulness.
You're missing the whole point of Carbon Events. They are for
*events*. You're suggesting they be used as dictionaries to hold
arbitrary data. That's just not their intended purpose, and it makes
no sense to define a whole new use for them which really just
replicates the functionality of CFDictionaries. It sounds to me as if
what you really want is a Resource Manager API that can flatten a
CFType and store it as a resource without having to go through the
intermediate step of using a Handle. If you had that you could store
all those things you're storing as parameters in the CE above as
values in a dictionary which could be saved directly to a resource
with something like AddCFResource. That might be a reasonable
enhancement to request, but your CE approach is not well conceived.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
