Re: NSValueTransformer problem with NSTextField update
Re: NSValueTransformer problem with NSTextField update
- Subject: Re: NSValueTransformer problem with NSTextField update
- From: "I. Savant" <email@hidden>
- Date: Thu, 1 Oct 2009 15:34:32 -0400
On Oct 1, 2009, at 3:26 PM, Paul Bruneau wrote:
I just thought of something IS said earlier:
Thing is, aside from transformed values, the value that makes it to
the model layer is usually a direct reflection of what was just set
in the view. :-) In 99% of cases, this would seem a waste of CPU
cycles to go back and make sure the view reflects the value it
itself just claimed to have set.
The key thing you said, IS, was "aside from transformed values"
which of course is exactly the case I am interested in. I am a
little surprised that more developers haven't wanted their text
fields to update to the reverse-transformed value after the user
commits the change. It seems that Cocoa could easily look to see if
a transformer is on the field, and do a reverse transform after entry.
I continue to be surprised that no one else has been bothered by
this difference in behavior between these common UI types. Maybe
transformers are very rarely used?
The problem is, I think, that most developers aren't overloading
the input as you are. :-)
You're allowing (if I'm counting correctly) three different modes
of input into the same text field with no indication, aside from the
formatting of the text, which format the user is inputting.
How about this (IMO) cleaner UI solution?
1 - Keep your base unit of measurement behind the scenes.
2 - Add a control that sets and shows (NSSegmentedControl, perhaps?)
the input format. Place it beside or below the text field.
3 - Use an NSFormatter (one for each input mode, swapped out when the
mode is changed) to format the input as required for that mode.
4 - Likewise, use an NSValueTransformer (one for each input mode,
swapped on mode change) to convert the currently-selected mode's input
to the base unit of measurement.
It might be slightly less-convenient in that you can't type in just
anything and have it magically formatted, but it ensures proper input
and, if done right, demonstrates to the user the expected input
format. It also frees you writing what is likely some very error-prone
parsing code.
Compare this to Apple's rocky love affair with natural language
date input in NSDateFormatter.
--
I.S.
_______________________________________________
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