Re: Custom Cell Bindings
Re: Custom Cell Bindings
- Subject: Re: Custom Cell Bindings
- From: Quincey Morris <email@hidden>
- Date: Sat, 03 Sep 2011 18:35:17 -0700
On Sep 3, 2011, at 17:45 , Seth Willits wrote:
> Let's go with an even simpler example. With a checkbox button cell, you click the button and a whole new value is generated.
>
> So let's say I make my own NSCell subclass which does the same thing. You click on something in the cell and a whole new value is generated. Now how do you get this new value into the original model object, which this value is a property of?
I thought this was already addressed.
You *can't* do this, based solely on the object value. There's nothing about the object value that provides sufficient information. As you've said.
In the context of a table view, it doesn't matter, because it isn't the NSCell's job to propagate the value replacement to the data model. It's the table view's job.
Now, it's possible that the previous sentence is literally false, if the table column is bound to an object and a property. In that case, it's possible that the table configures the NSCell by binding the correct object/property combination to it just before editing, and it really is the NSCell that makes the data model value replacement. In that case, the NSCell does have sufficient information in the binding. If that's so, you could do something similar, by introspecting the binding inside your NSCell subclass, but I don't know that the table view API guarantees that the NSCell binding is set for you from the column binding. (In particular, IIRC, you can bind the cell in IB separately from the table column binding, and I don't know what happens when the table cell is edited in that case.)
However, if the NSCell is used in a bindings-free context, then none of this applies. In this case, it's the owning control (the table view) that's really has to do the work. I think that's what Ken was trying to say -- the NSCell messages its control via 'sendAction:to:' to indicate that the object value has possibly been replaced.
Consider by contrast the case of a NSButton that is *not* bound to anything. In that case, pressing the button changes the button value, but that's not reflected anywhere outside the button itself -- it's up to the action method to retrieve the new value and modify the data model, somehow. Table views are a bit special because they contain a data source protocol that routes non-bindings value object replacements via a different mechanism.
_______________________________________________
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