On 2006-06-29, at 11:06:37, Eric Schlegel wrote:
I don't see what you mean here. Example?
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:
err = CreateEvent( kCFAllocatorDefault, kEventClassResource,
kEventResourceAdd, GetCurrentEventTime(), attributes, &eref );
err = SetEventParameter( eref, kEventParamDirectObject,
typeCFTypeRef, sizeof( dict ), &dict );
err = SetEventParameter( eref, kEventParamResourceID, typeSInt32,
sizeof( kMarksResID ), &kMarksResID );
err = SetEventParameter( eref, kEventParamResourceFile,
typeFSRef, sizeof( doc_ref ), &doc_ref );
err = SetEventParameter( eref, kEventParamFileFork, typeType,
sizeof( res_fork ), &res_fork );
err = SendEventToEventTarget( eref, GetResourceManagerEventTarget
() );
// 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.
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.
