Quincey pretty much got it right. Here's what happens: Table needs a cell (to draw, edit, type select, etc).
It calls -preparedCellAtColumn:row: -- this is a public funnel point, and can be overridden. Some examples on the dev site do this. preparedCellAtColumn:row does this, in this order (which may change slightly from release to release): * Return the tracking or editing cell (which was copied), if it is that given row/column. No modifications to the cell are done. * Acquires a cell, via: 1. Asking the delegate, 2. if nil, call [tableColumn dataCellForRow:] (this returns what was set in the nib) * Sets the object value, as returned from the datasource (if applicable) * Calls into bindings to fill up the cell with bound data; this potentially overwrites the objectValue * Sets properties on the cell, such as highlighted, backgroundStyle, showsFirstResponder * Lastly, calls -willDisplayCell, where you get a chance to overwrite any values set by the tableview. corbin On Oct 6, 2010, at 3:50 AM, jonat...@mugginsoft.com wrote: > > On 6 Oct 2010, at 11:29, Quincey Morris wrote: > >> >> This all means that anything you choose to configure in #1 may or may not >> still be in effect by the time you get to #2, but that's an implementation >> detail on which you cannot rely, because there's no API contract that >> anything is kept. >> > This seems to be an inescapable conclusion. I can configure certain aspects > of the cell in #1 but seemingly not others. > Perhaps the cell copying on edit/tracking that Corbin referred to has an > influence here. > But as you say, it's all dependent on the opaque detail of the implementation. > >> >> In many cases, #1 and #2 will be called in lockstep pairs, so it might seem >> that you could configure your cell in either place. However, because the >> delegates have separate purposes, configuration should be reserved for #2 >> only. >> > I agree. Identify the cell type in #1. > Configure it in #2. > > Thanks for taking the time to help clarify my murky thoughts on this. > > Regards _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
