On Sep 3, 2011, at 7:23 PM, Quincey Morris wrote: > OK, I went back to your original post, and I think I understand what you said > now.
Seems so! > The NSCell goes only as far as replacing its own "objectValue" with the > new/edited value. Correct. That's what I am expecting. > From there, it's the table view's job to propagate the new object value back > to the data model. Right. > So, how is the propagation triggered? I believe the answer lies in the fact > that table views *require* their column cells to be NSActionCell subclasses. I don't know that NSTableView requires the cells to be action cells. It's not documented anyway. But regardless, my subclass already is an NSActionCell subclass, but that doesn't change anything. It still doesn't propagate the value. It really seems to me that NSTableView only understands how to use NSTextFieldCell, NSButtonCell, etc subclasses. Hence, my thinking is since it doesn't work right out of the box as I'd expect, then perhaps there's some undocumented thing I'm supposed to be doing in my NSActionCell subclass which is half of the implementation. As in, perhaps my cell subclass is supposed to do X so the table view can correctly do Y to propagate the value. That's what I'm asking. The solutions I can come up with (and based on how the NS…Cells I tested and Ken did as well) all require me to add code into a table view subclass or a controller which just seems wrong. The table view shouldn't care what kind of cell it is, it should just watch for objectValue to change after some user interaction and send the object on its merry way via bindings or to the data source. -- Seth Willits _______________________________________________ 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]
