On Jul 31, 2006, at 5:03 PM, John Stiles wrote:
On Jul 31, 2006, at 2:45 PM, Wagner Truppel wrote:
John,
I tried your sample and I reproduced the first part of your
claim, but not the second, namely, that clicking on the field and
then switching tabs by means of the tab bar makes the field lose
its halo. The halo never went away when I tried it, no matter what.
It seems to me that the behavior you described is normal and
correct. After all, once the field has gained focus, it remembers
that it has the focus. Switching to another tab should not make
the field lose its focus since the field isn't accessible anyway
until the user returns to that tab, in which case the state of
the application is as it was when the user last left that tab view.
Or perhaps I misunderstood your problem and am missing something. :)
The problem is that the text field can have a halo but not
actually have focus.
Please use the buttons to switch between tabs, not the tab bar. In
the real code, it's a "tabless" tab view; the user can only
navigate with buttons, not with the tab bar. Maybe I should have
hidden the tabs in the sample, too, but I wanted to make it
apparent that I was using an NSTabView.
This really sounds like a bug I filed last year. Unfortunately, it
no longer shows up in my list of bugs, but I do remember it coming
back as "behaves correctly".
Anyhow, I too make use of tabless tab views (sometimes nested ones)
and there were situations where controls would lose focus. This
was especially problematic with full keyboard access turned on as
the user would be put into a state where the window itself would
have the focus; thus preventing them from tabbing to anything.
A workaround I employed was to set my controller as the tab views
delegate and then implement tabView:didSelectTabViewItem:
In that method, I query whether or not the window is the first
responder, and if so, set up an appropriate first responder
(NSWindow's makeFirstResponder:) for the particular tab that is
showing.
