Re: NSCell subclassing nightmares
Re: NSCell subclassing nightmares
- Subject: Re: NSCell subclassing nightmares
- From: Graham Cox <email@hidden>
- Date: Mon, 29 Jun 2009 15:25:50 +1000
On 29/06/2009, at 1:10 PM, Chase Meadors wrote:
Well, in the montage of problems that arose from this, I found out
more about how cells work, but I'm still confused. It took me
forever to discover that the weird problems with bindings I was
experiencing stemmed from the fact that there is ONE cell for a
table column, that it uses to draw all its data.
[]
In short, a value change that should affect one cell affects all of
them. Some magic is happening in Apple's cell classes that makes
values affect only the intended cell. Sorry if I'm missing something
obvious here... but I'm completely stumped.
Well, you discovered that a table column has but one cell. That's the
key to this problem - a cell used by a table view can't have any
persistent internal state (like an animation frame count for example)
because it is continually being re-used.
The "magic" you're referring to is that the table fetches the data for
the cell on the fly every time - it doesn't store it anywhere, so it
can re-use the cell.
You can return a specific cell for each row using -dataCellForRow: but
you have to manage it properly. Just alloc/initing one every time
isn't good enough (who is going to release these cells?) - you'd have
to maintain a list of cells in your controller, one for each row, and
return the appropriate one each time if you need its internal state to
last across calls to the table view. I doubt that "infinite" cells are
being created, but it certainly could be a very large number, all of
which seem to be leaking.
Or just give up and do things in the standard way - sometimes certain
"cool" effects are simply not worth the trouble. ;-) Custom cells can
be very hard work, especially in table views.
--Graham
_______________________________________________
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