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.
