Re: NSTabView and edit fields

FROM : John Stiles
DATE : Tue Aug 01 02:53:21 2006

On Jul 31, 2006, at 5:24 PM, Ricky Sharp wrote:

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


That sounds awful! I think my bug is different though. It's purely a 
visual artifact—the NSTextField is drawing a halo even though it 
doesn't have focus, but everything else works. And if you give the 
text field focus normally (e.g. press tab or click inside of it), 
everything goes back to normal.

Oh well. I don't have a workaround yet, unfortunately. I'd hate to 
ship it this way, but I can't seem to find a solid fix.