That is, the the CFTypeID of the object should be the OSType used
in several key OS X technologies.
I don't know what cfctypes is, but as far as CFTypeIDs should be
OSTypes rather than small ints, well... This is implementation
detail and they might prefer to use indices in array for efficiency
to not incur additional lookup.
// CFBase.h
typedef UInt32 CFTypeID;
An OSType resolves to a UInt32.
A UInt32 resolves to an unsigned long.
FourCharCodes, ResTypes, and Desc types are the same.
CarbonEvents, AppleEvents, OSA, and of course, our venerable
Resource Manager. Not to mention everything that qualifies for
toll free bridged Cocoa objects. The implications are quite far
ranging. For instance, AppleEvent object support for Carbon that
would probably be better than what's available in Cocoa so Carbon
apps would be scriptable with a minimum of effort.
I don't quite see how this is connected.
Whoa!
* In Carbon, there are typed events, and typed data.
* In AppleEvents, there are typed events, and typed data.
* In OSA, most everything comes though as typed data -- AEDescs or
AppleEvents.
* In OSL, everything comes throught as typed data -- AppleEvent
object descriptors, AEDescs, and AppleEvents.
* AppleScript Studio runs on AppleEvents, AE object descriptors, and
AEDescs bridged through to Cocoa's events and objects.
* Resource files are indexed typed data.
If you can't see a connection maybe someone else can chime in and
interpret what I'm trying to get across in a vocabulary closer to
what you know. I think I'm describing things in common and well known
MacOS terms.
CFTypeRef cf = NULL;
err = GetEventParameter( theEvent, ..., typeWildCard, ... &cf );
err = AddCFResource( refnum, some32bitID, &cf ); // Resource
Manager knows the type because it's available from object.
CFDictionaryRef dict = NULL;
err = GetCFResource( refnum, some32bitID, &dict ); // Resource
Manager knows the type because it's available from object.
I don't quite follow what are you proposing here. Clarify?
I'm proposing that CFTypeRefs carry their FourCharCode mnemonics
around in their classes (structs). Implicit in the above is auto-
coercion of CFTypes for various purposes.
Because resources are stored as indexed pairs - {OSType, Handle}, the
Resource manager could then do the conversion of any CFType into a
handle and because the input object has its type available, pump it
into typed resource. And vice versa on the way out. Actually, it
wouldn't do the conversion directly, but simply snag a CFDataRef from
a switch on the type and then get a Handle from it.
Direct support in CarbonEvents:
enum {
kEventClassResource = 'rsrc',
kEventResourceRead = 'read',
kEventResourceAdd = 'radd',
kEventResourceUpdate = 'upda',
....
I don't see what you mean here. Example?
Larry Harris:
I can't quite see when these would be useful enough for them to
implement them. Can you give some examples?
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.
Philip Aker
email@hidden
_______________________________________________
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
