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 protected])

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to