Re: Question about KVC-compliance and bindings
Re: Question about KVC-compliance and bindings
- Subject: Re: Question about KVC-compliance and bindings
- From: Per Bull Holmen <email@hidden>
- Date: Tue, 28 Feb 2012 22:02:58 +0100
Den 20:24 28. februar 2012 skrev Quincey Morris
<email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden