Thread-topic: Cocoa bug? Arrow keys stop working in table view
User-agent: Microsoft-Entourage/11.2.3.060209
On or about 7/29/06 6:29 AM, thus spake "email@hidden"
<email@hidden>:
> Date: Fri, 28 Jul 2006 20:54:07 -0700
> From: Andrew Merenbach <email@hidden>
> Subject: Re: Cocoa bug? Arrow keys stop working in table view
> To: Corbin Dunn <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Thanks for the tip, Corbin, but I'm still a little confused. Why
> does my custom table view support arrow-key navigation when it is
> *not* inside of a tab view? Making it a subview of a split view or
> basic custom view doesn't disable the arrow keys; why should putting
> it inside a tab view (using the "Make subviews of" menu in IB) make
> any difference at all as to whether super's keyDown: is being called?
>
> Cheers,
> Andrew
>
> On Jul 28, 2006, at 6:03 PM, Corbin Dunn wrote:
>
>>
>> On Jul 28, 2006, at 5:38 PM, Andrew Merenbach wrote:
>>
>>> Hi, all. I wonder whether I've found a possible bug with the
>>> Cocoa GUI system. I have an NSTableView that I subclassed for
>>> delete-key and escape-key support, amongst other things. For some
>>> reason after I put the table view inside of a tab view (as the
>>> only child view of the first tab view item, I might add) the
>>> default (untouched!) arrow-key support stops working.
>>>
>>> My key-handling code is as follows:
>>>
>>> - (void)keyDown:(NSEvent *)event {
>>> consumedKeyDown = NO;
>>> [self interpretKeyEvents:[NSArray arrayWithObject:event]];
>>> if (!consumedKeyDown) [super keyDown:event];
>>> }
>>>
>>> - (void)doCommandBySelector:(SEL)selector {
>>> consumedKeyDown = [self tryToPerform:selector with:nil];
>>> }
>>>
>>> (Where consumedKeyDown is a BOOL instance variable set to NO in -
>>> awakeFromNib.)
>>>
>>> Switching the table's class back to a regular table view solves
>>> the problem, as does commenting out the one line in -
>>> doCommandBySelector:
>>>
>>> I haven't been able to find anything in the docs or in the
>>> archives to explain the lack of arrow key functionality that I'm
>>> experiencing. Does anyone have any pointers? Is the tab view
>>> interfering with the arrow keys somehow?
>>>
>>
>> The keyboard nav for tableviews is handled in [super keyDown:].
>> Chances are, you aren't calling it. You may want to special case
>> those keys to let them through.
You could easily have answered this question with a few well-place NSLog
calls in your code. It isn't a Cocoa bug; it is your coopting of the
responder chain's message-handling that is faulty.
A down-arrow key (let's say) corresponds, when translated through
interpretKeyEvents, to moveDown:. But moveDown: is not implemented by
NSTableView! So when you call tryToPerform:, the moveDown: message
percolates up the view hierarchy, looking for someone to handle it.
NSTabView *does* handle it - so that's the end of that.
When the NSTableView is not in a tab view, on the other hand, *no* handler
for moveDown: is found. So the keyDown is not consumed, and [super keyDown:]
is called - giving the table view a chance to do what it is supposed to do
in the first place when a down-arrow is pressed.
In other words, it was just sheer luck that your code *ever* worked.
m.
--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide - Second Edition!
http://www.amazon.com/gp/product/0596102119
Take Control of Word 2004, Tiger, and more -
http://www.takecontrolbooks.com/tiger-customizing.html
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
