Den 20:24 28. februar 2012 skrev Quincey Morris <quinceymor...@rivergatesoftware.com> følgende:
> > I don't think there's no shortcut. :) > > It's not clear from your description, but you seem to saying that there *is* > a value object (of some custom class?) for "mainBranch". And a "subBranch" > object? In that case, you don't have to override the controller's > valueForKeyPath: to intercept "mainBranch.subBranch.nonExistentAttribute". > Instead, override the subbranch object's valueForUndefinedKey: -- and also, > if there are non-existent subbranches, the main branch's > valueForUndefinedKey:. That allows you to avoid messing with the > higher-traffic valueForKeyPath:. Thanks. I try to tell myself, either give enough information, or give no information at all. I clearly didn't give enough this time. Currently there is no value object for mainBranch, because I haven't started programming that part yet. My plan, my proposed Evil Shortcut, was to have no objects at all to represent this chain of properties... because there is virtually no custom behaviour associated with it. In the meanwhile I've been thinking about it, and thought that there isn't really much added complexity to making my own objects to represent each link in the chain. Thanks for reminding me about valueForUndefinedKey: , probably I will instead override valueForKey: , and call super at the end if I don't find an associated parameter for the plug-in. So, the two key paths for the controller will be: values.customAudioUnitPropertyName parameterInfo.customAudioUnitPropertyName.[ minValue | maxValue | isWritable | parameterName ] The first path is the complex part and is already implemented. My question was concerning the second path, the easy part, and I will do pretty much what you suggested. The user of the controller will have to provide a delegate which translates between customAudioUnitPropertyName and an integer propertyID or parameterID (coreaudio lingo) which is needed to talk to the plug-in. When a name is translated once, it is inserted into an NSMapTable so valueForKey: will be very efficient the second time for the same key. The parameter info (second path) will be very rarely accessed, so performance is probably of no concern. Thanks for your help! Per _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
