Thank you Hank .... that is just what I needed to see. I must've glossed over the docs you reference below. But something just occurred to me with respect to your point regarding UITableViewCells, userinfo and NSIndexPath. If I associate an NSIndexPath* with a timer and I insert 10 timers - each into the top position of a UITableView; then at each insert, all previous * NSTimers.userInfo.nsIndexPath* values become incorrect. In fact, every timer will have an NSIndexPath with row=0 & section=0 if I'm inserting them all into the top. The problem is that userInfo properties will be static while the underlying rows in the table can keep changing.
And, if, on insert, a UITableView simply bitblts the cells shifting down ... I'm not sure I'll get a chance to update the timers with their new NSIndexPath? Is there a class or delegate method that gets invoked for every visible cell when the cell's shift down? I need to store something in userInfo that tells me or helps me definitively find the correct Cell to update ... Thanks, -Luther On Wed, Sep 16, 2009 at 8:08 PM, Hank Heijink (Mailinglists) < [email protected]> wrote: > On Sep 16, 2009, at 8:24 PM, Luther Baker wrote: > > I'd like to fire a simple callback every .1 of second (yes, my stopwatch >> style app). But in that callback, I need access to a corresponding >> UITableViewCell. Unfortunately, I don't see a way to choose a selector >> with >> a UITableViewCell argument for the oneliner: >> >> [NSTimer scheduledTimerWithTimeInterval:<#(NSTimeInterval)ti#> >> target:<#(id)aTarget#> selector:<#(SEL)aSelector#> >> userInfo:<#(id)userInfo#> >> repeats:<#(BOOL)yesOrNo#> >> > > Yep, that's what the userInfo parameter is for. It's an id, so you can pass > your UITableViewCell there, and get it back in the method you pass in the > selector argument by calling the -userInfo method on the NSTimer instance > (see below). > > [...snip approach using NSInvocation...] > > but this approach requires roughly 7 extra lines of code every time I >> configure a cell for display (creating things like NSMethodSignature, >> NSInvocation, setters, etc). It isn't enormous but suddenly, my generally >> small cellForRowAtIndexPath is getting pretty long. I'm wondering if I >> should be careful. Things like scrolling etc might blast through this and >> I'd prefer to keep the method fairly light if, there was in fact a way to >> use the simpler one liner to invoke a callback with an arg. >> > > Passing UITableViewCells around is risky business: if the cell scrolls off > the screen, you're pointing to a cell in the reuse pool (provided you stick > to the standard paradigm), which will most likely lead to trouble, depending > on what you're doing. You might be better off passing an NSIndexPath, and > then asking for -[UITableView cellForRowAtIndexPath:], which will return nil > if the cell is not visible. > > Again. I certainly appreciate any informal feedback/suggestions. Maybe >> userInfo would apply for what I'm doing here? I thought userInfo would be >> stored in the NSTimer and unfortunately, the single callback that >> everything >> is firing to doesn't take the NSTimer as an arg so I think that means I'd >> be >> tracking NSTimers external to the callback loop ... and I'd just rather >> avoid that. >> > > Are you sure your method has the right signature? If you pass a selector > that doesn't accept arguments, everything will work, but see the following > from the documentation of NSTimer: > > The selector must have the following signature: > > - (void)timerFireMethod:(NSTimer*)theTimer > > The timer passes itself as the argument to this method. > > Hope this helps, > Hank > > _______________________________________________ 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]
