Re: [bug #13916] NSTextField doesn't disable properly

[Matt Rice]

--- David Ayers <ayers@fsfe.org> wrote:

> Matt Rice schrieb:
> > 
> > --- matt rice <INVALID.NOREPLY@gnu.org> wrote:
> > 
> > 
> >>Follow-up Comment #1, bug #13916 (project
> gnustep):
> >>
> >>I commited something to fix this partially,
> >>it still doesn't draw gray or whatever when
> disabled
> >>but will no longer allow the user to edit it.
> > 
> > 
> > forgot to mention additional testing showed a
> > disabling a NSTextField causes it to reset its
> string
> > value to an empty string.. the same for
> NSComboBox,
> > though i didn't test NSTableViewHeaderCell, so i
> > added/documented this behaviour
> > 
> 
> Really?  Wow, I find reseting the value when
> disabling very inconvenient.
> 

yeah, I was rather unhappy about it myself, so i'm all
in favor of giving it the boot

> At least for WO4.5 with an additional association to
> enable/disable the
> text field, the net result is definitely not a
> cleared text field (the
> text color is grayed), yet I'll have to spend some
> time to analyze
> whether it is cleared and reset.  (GDB isn't working
> properly so I'll
> need to do some posing.)


my guess is it is new to 10.3 as that seems to be when
-placeholderString/-setPlaceholderString: were added
according to the release notes,

so the reason its setting a disabled text field to an
empty string seems to be so it will show its place
holder... and i couldn't figure out a way to disable
it from happening...

anyhow, i guess i'll just revert it, and if someone
wants to come up with a more comprehensive placeholder
patch... (preferably one which allows developers to
opt-out, via a nil placeholderString or whatever),
by all means..





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com