Re: NSTabView and edit fields
Re: NSTabView and edit fields
- Subject: Re: NSTabView and edit fields
- From: John Stiles <email@hidden>
- Date: Mon, 31 Jul 2006 13:54:48 -0700
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@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden