--- David Ayers <[EMAIL PROTECTED]> wrote: > Matt Rice schrieb: > > > > --- matt rice <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
