Re: NSTextField Bug? Can't be!
Re: NSTextField Bug? Can't be!
- Subject: Re: NSTextField Bug? Can't be!
- From: Seth Willits <email@hidden>
- Date: Tue, 12 Aug 2008 13:15:49 -0700
It really does not have anything to do with resigning first responder.
You can clearly ask for the string value while the text field is first
responder and get the correct answer back. What's happening is plainly
obvious, I just think it's a bug. (I filed a report. We'll see what
happens.)
--
Seth Willits
On Aug 12, 2008, at 4:08 AM, email@hidden wrote:
Seems to me that this might be more to do with the responder chain.
The NSTextField will update its stringValue when it resigns as first
responder.
An NSButton does not accept first responder status so the
NSTextField never gets to resign first responder status.
If you are using NSViewController call -commitEditing in your button
click method. This will commit any pending edits.
Otherwise send -makeFirstResponder: to the view's window with the
window itself as the argument. Similar effect.
This situation happens frequently. It's one good reason to always
use NSViewController.
Check out NSEditor (Informal Protocol) and NSEditorRegistration
(Informal Protocol) for the low down.
Jonathan.
FROM : Seth Willits
DATE : Tue Aug 12 10:28:30 2008
Right. I figure though that asking for stringValue grabs the text
from
the field editor, so why doesn't setEnabled do the same to commit
current editing? Seems logical to me. I can't imagine a situation
where you'd want text the user typed into a field to be ignored after
they already typed it.
--
Seth Willits
On Aug 11, 2008, at 10:40 PM, Graham Cox wrote:
> I suspect it's because of the Field Editor. The text isn't really
> "in the field", it's in the shared field editor. If the field is
> disabled, it won't be updated from the field editor because
disabled
> means "refuse input". Also, it may be that when a control that is
> using the field editor is disabled, it disconnects from the field
> editor and clears its contents.
>
> You could try calling -validateEditing on the field prior to
> disabling it, which should copy over the text content from the
field
> editor so that the field indeed does have this value.
>
> hth,
>
> cheers, Graham
>
>
> On 12 Aug 2008, at 3:31 pm, Seth Willits wrote:
>
>>
>>
>> If a text field has focus, you type "blah blah blah" into it, and
>> then click a button which asks for its string value and disables
>> the text field, you get "blah blah blah" back.
>>
>> If a text field has focus, you type "blah blah blah" into it, and
>> then click a button which disables the text field first and then
>> asks for its string value, you get an empty string...
>>
>>
>> I can make up some reasoning in my head for why that'd make sense,
>> but it just doesn't sit well with me. If the text is *IN THE
FIELD*
>> before the field is disabled, then clearly it should be considered
>> its string value. I can't imagine this being a bug simply because
>> *somebody* would have noticed and fixed it by now, but I can't
>> understand why this would be desirable behavior.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden