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 (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
