On May 3, 2012, at 13:46 , Marc Respass wrote:
> Can anyone point me in the right direction on this? How can I prevent
> tableViewSelectionDidChange: from being called when the user is holding the
> up or down arrow and trying to scroll rapidly through the table so I only
> update when they stop?
One approach is to move the heavyweight code out of your selectionDidChange
method into a separate method, the invoke this new method via
'performSelector:…afterDelay:0' (or, maybe better still, 'afterDelay:0.1'). In
order to prevent the performs from stacking up, you would always invoke
'cancelPreviousPerformRequestsWithTarget:selector:object:' first.
That is, you always write something like this pattern:
[cancelPreviousPerformRequestsWithTarget: self selector: @selector
(mySelectionDidChange:) object: nil];
[self performSelector: @selector (mySelectionDidChange) withObject: nil
afterDelay: 0.1];
so you have a queue of 0 or 1 pending selection change actions at any time, and
the action is done "soon if not canceled first".
Other approaches are to use NSOperationQueue to schedule a separate operation,
or GCD to schedule a separate block, to the same effect. With a bit more
trouble and attention to thread safety, you could arrange for either of these
to be done on a background thread, if performance considerations warrant the
extra effort.
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
