El may 3, 2012, a las 7:27 p.m., Quincey Morris escribió:
> On May 3, 2012, at 16:07 , Marc Respass wrote:
>
>> Do I have that correct?
>
> Yes, you do. :)
>
> Another way to think about it is this: the cancel suppresses all the selector
> performs except the last one. (There's *always* a last one because the cancel
> is done first.) The last one is the only one you really care about or want.
Excellent. Thank you again. [NSEvent keyRepeatInterval] returned 0.833333 so I
set the delay to 0.9 and it works perfectly. What was a slow process is now as
smooth as can be. It even works correctly if I hold the up/down arrow until I
get to the end. The delay to display once I stop the repeat is not noticeable.
I just moved my selection code to a method and replaced it with this
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil
afterDelay:0.09];
I've been working for days profiling this app to increase the responsiveness of
this app and I've made a lot of progress (table view selection change used to
take 0.3 seconds, now 0.014) but this is the final straw that will really make
a difference.
Thanks very much!
Marc
_______________________________________________
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
