Re: NSTabView and edit fields

FROM : John Stiles
DATE : Mon Jul 31 22:54:48 2006

I didn't get any replies to this, so I reduced it down to a quickie 
sample.

To get it, go to the Finder and choose "Go > iDisk > Other User's 
Public Folder". For the member name, type "jmikros." The file you 
want is called "TabViewsAndTextFields.zip."

The behavior is really odd. I'm finding that the bug is fairly 
consistent:
• You need a tab view with an editable NSTextField, and a default button
• Type into the tab view
• Press return to activate the default button
• The default button changes the selected tab view

At this point, you've triggered the bug—when you return to this tab, 
the edit field will not have first responder status, but it will have 
a halo around it. The halo is not just a double-buffering artifact, 
because you can resize the window or call setNeedsDisplay and the 
halo refuses to go away. As far as I can see, the only way to remove 
the halo is to give that NSTextField first responder status and then 
take it away.

Unsuccessful workaround attempts:
- Call -endEditingFor on the window to force the edit field to lose 
focus
- Call [myWindow makeFirstResponder:myWindow], again to force the 
edit field to lose focus
- Clear the contents of the edit field
- Force the edit field to re-render itself via -setNeedsDisplay or -
display.

I'd really appreciate it if someone would download my demo and see if 
they notice anything obviously wrong with it. The code is dead simple:

- (IBAction)goToFirstTab:(id)sender
{
   [myTabView selectTabViewItemAtIndex:0];
}

- (IBAction)goToSecondTab:(id)sender
{
   [myTextField setStringValue:@""];
   [myWindow makeFirstResponder:myWindow];
   [myTabView selectTabViewItemAtIndex:1];
}

Thanks in advance to all :)


On Jul 27, 2006, at 7:15 PM, John Stiles wrote:

> I'm using a "tabless" NSTabView to make a quick "Assistant" or 
> "Wizard"-like dialog. The first tab explains what's going on to the 
> user, the second tab has edit-text fields, the third tab shows 
> networking progress, and the fourth tab reports success or failure. 
> If there are problems, the user is given the option to go from the 
> final pane back to the second pane and correct their edit-text 
> entries.
>
> I'm noticing that, when going from the last pane back to the second 
> pane, sometimes the edit-text fields have residual "halos" around 
> them as if they could be edited, and/or grayed-out text selection 
> boxes. The halos aren't valid, however—none of the edit fields are 
> actually active. It's just a visual glitch; if I tab through all 
> the edit fields, everything is fixed. I
>
> I don't know the best way to work around this, unfortunately. I 
> tried calling [myWindow endEditingFor:nil] before every call to 
> [myTabView selectTabViewItemAtIndex:something], but that doesn't 
> seem to have solved the problem. I could try forcing all the 
> controls to redraw, but that seems like a sledgehammer.
>
> Am I doing anything wrong? Has anyone else seen this?
>
> Thanks for your help :)
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jstiles%
> 40blizzard.com
>
> This email sent to <email_removed>