Re: NSCell subclassing nightmares
Re: NSCell subclassing nightmares
- Subject: Re: NSCell subclassing nightmares
- From: Quincey Morris <email@hidden>
- Date: Sun, 28 Jun 2009 22:19:39 -0700
On Jun 28, 2009, at 20:10, Chase Meadors wrote:
I'm making a custom cell that will 'animate' in a sense. Each of
these cells holds an NSTimer. The object value sets a bool that
determines whether the code inside the timer's method is executed or
not. The code in this method simply increments a value and requests
the table view to redraw. So the object value effectively starts and
stops the animation.
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.
Through google, I read about implementing -copyWithZone:, but
breakpoints in this method never get called...
I tried overriding table column's -dataCellForRow: and returning a
new cell [[MyCell alloc] init]. This, however, apparently causes
infinite cells to be allocated, and a crash happens.
No, that's the wrong approach. You want to create *one* cell for each
animation, the first time it's appropriate in dataCellForRow. After
creating it, you must associate the cell with the row that it belongs
to, through some scheme you invent (like a NSMutableDictionary with
suitable keys) so that the next time you're asked for the cell at
dataCellForRow you can return the *same* cell. When the animation is
complete, you need to arrange for the cell to be disposed of.
_______________________________________________
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