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.
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.
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!
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.
_______________________________________________
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
