Re: how to prevent TableView update on key repeat?
Re: how to prevent TableView update on key repeat?
- Subject: Re: how to prevent TableView update on key repeat?
- From: Marc Respass <email@hidden>
- Date: Thu, 03 May 2012 18:27:40 -0400
Thanks Quincey (and Alex),
I ended up finding a solution that almost works perfectly.
- (void)tableViewSelectionDidChange:(NSNotification *)aNotification;
{
NSEvent *event = [NSApp currentEvent];
if(event != nil && [event type] == NSKeyDown && [event isARepeat])
{
return;
}
else
{
// do my thing
}
}
The problem is that it doesn't update the last row since you get there in a repeat event. I don't love the "do thing with delay," it feels too fragile. I need to update every time the selection changes except when repeating. That's the only condition. If repeating, wait until stop but, naturally, the table view only sends on change.
What I guess I'm looking for is more like the ability to send tableViewSelectionDidChange: after keyUp. Since the code above is working so well, maybe it's a reasonable idea to subclass NSTableView, note that I'm in a key repeat and send the notification in keyUp if "wasRepeating" is YES. That doesn't sound too bad, not too much code, no threading issues.
Marc
El may 3, 2012, a las 5:28 p.m., Quincey Morris escribió:
> 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 (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