1. Apple-Dev | Cocoa
  2. Topics

problems with tab key and custom views

James Walker
 

I have a window with 3 views that I want to be able to switch focus between using the tab or shift-tab keys.  Going by the view programming guide, it seems like I shouldn't have to do anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

If I override keyDown: and call interpretKeyEvents:, that doesn't switch to the next view.  So it seems like I must explicitly test for tab and shift-tab events and handle them somehow.


Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil.  Yet, if I call nextKeyView, it returns a non-nil view that is visible and accepts first responder status, so it seems like nextValidKeyView is not working as documented.  If I find the next key view the hard way and make it first responder, it does become first responder, but it seems like it shouldn't be so hard.
Quincey Morris
 

On Dec 12, 2017, at 13:22 , James Walker <list2@...> wrote:

I have a window with 3 views that I want to be able to switch focus between using the tab or shift-tab keys.  Going by the view programming guide, it seems like I shouldn't have to do anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

You shouldn’t have to do anything else. I just tried it in a standard single-window document template with 3 text fields in the window, and it worked fine without any code.

Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil. 

I’ve never tried to use “selectNextKeyView:” but, looking at the documentation, it doesn’t seem to do the obvious thing (use the “nextKeyView” object). Instead, the documentation seems to say that it looks for the “closest” (geometrically, I assume) view in the rest of the next-view loop. This was consistent with my test. When I used “nextKey” to specify a different order for my text fields, the Tab key still jumped between them in geometry order.

Given all that, I’d have to assume that something is causing your window not to be key, or is causing something *else* in the window to be first responder — something at a different level in the view hierarchy. Do your 3 views have subview that can accept first-responder status? If you force one of them to be first responder, what does the Tab key do then?

Finally, don’t forget that windows have an “initialFirstResponder” property that you can use if its default initial choice isn’t what you want.
James Walker
 

On 12/12/2017 1:59 PM, Quincey Morris wrote:
On Dec 12, 2017, at 13:22 , James Walker <list2@...> wrote:

I have a window with 3 views that I want to be able to switch focus between using the tab or shift-tab keys.  Going by the view programming guide, it seems like I shouldn't have to do anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

You shouldn’t have to do anything else. I just tried it in a standard single-window document template with 3 text fields in the window, and it worked fine without any code.

Hmm, you're right, it worked in a toy project for me.

Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil. 

I’ve never tried to use “selectNextKeyView:” but, looking at the documentation, it doesn’t seem to do the obvious thing (use the “nextKeyView” object). Instead, the documentation seems to say that it looks for the “closest” (geometrically, I assume) view in the rest of the next-view loop. This was consistent with my test. When I used “nextKey” to specify a different order for my text fields, the Tab key still jumped between them in geometry order.

Given all that, I’d have to assume that something is causing your window not to be key, or is causing something *else* in the window to be first responder — something at a different level in the view hierarchy. Do your 3 views have subview that can accept first-responder status? If you force one of them to be first responder, what does the Tab key do then?

Finally, don’t forget that windows have an “initialFirstResponder” property that you can use if its default initial choice isn’t what you want.

Not counting the window's content view, there is only one level in the view hierarchy.

I suspect that the problem is a side effect of the (shameful) fact that my app is a Carbon app, so there is some nonstandard handling of events and windows going on.  Anyway, I wrote my own implementations of nextValidKeyView and previousValidKeyView and made all my views use those, and now tab and shift-tab are changing the first responder appropriately, without doing anything special in keyDown:.

1 - 3 of 3