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 19:07:40 -0400
El may 3, 2012, a las 6:47 p.m., Quincey Morris escribió:
> On May 3, 2012, at 15:27 , Marc Respass wrote:
>
>> 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
>> }
>> }
>
> Well, apologies in advance for being curmudgeonly, but this is a crummy solution.
Not at all. That's why I am asking and responded with something I found. I apologize if I came across ungrateful. I do appreciate the help.
> You don't know, at the time this method is called, what the current event is. The table view itself might already have deferred sending the notification until some other event occurred (e.g. a NSTimer expiration, or it may even have done its own performSelector…afterDelay). That means that pressing a random key after an arrow key might suppress the detail update entirely.
Good points.
> On top of that, you're ready to jump in and double your hack by subclassing NSTableView to "fix" the problem the first hack had with keyUp events. Ugh!
OK, not a good idea. Unreadying myself :)
> The technique I suggested, of performing a selector and canceling unwanted performs, isn't "fragile". It's a well known (though not immediately obvious) pattern that works well in situations like this. I didn't invent it, I just learned it from someone else on this list. It also has the distinct advantage (in stark contrast to your hack) of being provably correct.
It felt to me that performing a selector after a fixed delay would be fragile. I think that I simply didn't understand how running the code via perform selector after delay will solve the problem.
Let me ask if I have figured it out. User presses down, selection did change is called, I cancel previous performSelector then perform with delay of 0.1 seconds. The key repeat is much faster than 0.1 so selection did change is called before the selector is called and then it is canceled (the cycle then repeats). When the user lifts the key and selection stops, selection did change is *not* called, the selector is scheduled to fire, and it does. If I have that right, then I simply paste the two lines you provided
[cancelPreviousPerformRequestsWithTarget: self selector: @selector (mySelectionDidChange:) object: nil];
[self performSelector: @selector (mySelectionDidChange) withObject: nil afterDelay: 0.1];
and I'm done. Do I have that correct? If so, I apologize that I didn't pay enough attention to get it the first time.
Thanks a lot
Marc
_______________________________________________
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