Re: mechanism for "conditional binding" depending on class of selection
Re: mechanism for "conditional binding" depending on class of selection
- Subject: Re: mechanism for "conditional binding" depending on class of selection
- From: Miguel Sanchez <email@hidden>
- Date: Mon, 16 Jan 2006 14:43:33 -0800
does this help? [ from the thread "Bindings for subclass properties"]
--------
On Jan 16, 2006, at 9:48 AM, Dan Price wrote:
I can't simply add keys for subclass properties to the
controller (there are a lot of them!) because they are
not applicable to Shape and XCode complains. Any
ideas? Any help appreciated.
Uncheck 'Raises For Not Applicable Keys' (NSRaisesForNotApplicableKeys).
mmalc
---------
- Miguel
On Jan 15, 2006, at 2:59 PM, Eric Miller wrote:
Hi -
I'm seeking advice for the "right" way to do something, or if there's
a mechanism for doing what I need already in place.
My data model is basically an array of subclasses of some base class
(call it Node). The subclasses (RemoteNode, LocalNode, etc) may all
have different data fields in addition to the base class' fields. I
have a master-detail type interface. I want the inspector pane to
change automatically depending on the subclass of Node currently
selected.
That part is working, but I find that the views associated with Node
types that *aren't* currently selected — they're invisible — are still
trying to pull new values from the new selection, resulting in
exceptions saying "Blahblah is not key-value coding compliant for the
key yadda yadda."
So if RemoteNode has a url field and its inspector shows this, then
when a LocalNode (which does not have a url field) is selected, the
RemoteNode's url field throws since the selection has changed, but
nodeController.selection.url does not exist. Make sense?
Ideally, I'd like to bind the views to the data model conditionally.
Even more ideally, the condition would include access to the class of
the controller's selection in IB. Maybe that's asking a lot. =)
Anyway, it seems like there should be some elegant way to do this, but
I can only come up with kind of ugly ways to do it.
TIA for advice.
Eric Miller
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden