Re: NSOutlineView multi cell type binding query
Re: NSOutlineView multi cell type binding query
- Subject: Re: NSOutlineView multi cell type binding query
- From: Quincey Morris <email@hidden>
- Date: Wed, 6 Oct 2010 03:29:48 -0700
On Oct 6, 2010, at 02:58, email@hidden wrote:
> What does work is:
>
> 1. in - outlineView:dataCellForTableColumn:item: construct my popup cell when required.
> 2.in - outlineView:willDisplayCell:forTableColumn:item: select item in popup cell according to model.
>
> In step 1 I construct my cell and select the item that corresponds to my model.
> This selection is not respected when the cell is drawn unless I implement step 2.
> I don't quite understand this as the cell is being configured on a per item basis.
AFAIK the purpose of these delegate methods is as follows:
1. outlineView:dataCellForTableColumn:item: is responsible for customizing the management (creation, caching, etc) of possibly persistent cells, deciding things like how many cells are kept around and how they're shared between rows, columns and the table as a whole. This method is *not* responsible for configuring the cell for any individual use. You don't even know for sure that the cell being requested is actually going to be used imminently for drawing.
2. outlineView:willDisplayCell:forTableColumn:item: is responsible for customizing the properties of whatever cell has been chosen (by built-in behavior or by delegate method #1) for a specific table/column/row combination.
AFAIK, certain cell properties such as the object value are configured by the table for the cell chosen for a specific column/row combination *after* #1 but *before* #2.
In other words, the cell is not configured before #1, nor is it expected to be configured by #1. It is given a default configuration before #2, which means that #2 needs only to re-configure properties that require non-default values.
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.
Therefore what you have said you're doing sounds to me like *exactly* the correct approach for #2, but your #1 shouldn't even be trying to set up the cell's selected index.
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.
That's how I understand it, anyway.
_______________________________________________
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