Re: NSValueTransformer problem with NSTextField update
Re: NSValueTransformer problem with NSTextField update
- Subject: Re: NSValueTransformer problem with NSTextField update
- From: Paul Bruneau <email@hidden>
- Date: Thu, 1 Oct 2009 15:26:29 -0400
On Oct 1, 2009, at 2:16 PM, Quincey Morris wrote:
What was the number you tried this with? Some NSNumber values are
singleton objects, so returning a "new" NSNumber with the same value
might really return the original object. :) Or maybe just equality
of value matters.
It occurs to me that the singleton-ness of the underlying NSNumber
objects may have something to do with why the text fields didn't
behave as you expected to begin with. Or the equality.
I like the way you think :) But I just went back and tried a wide
variety of ridiculous numbers with no change. It seems to be based on
the equality.
Maybe the lesson of all of this is that using a value transformer to
control formatting (that is, when the transformed string has a
preferred but not unique form) is not such a good idea.
Well I'm not really controlling formatting with it (more below). I
just make sure the formatting looks the way I want it to in my reverse
transform.
I can't remember now -- was there a reason why a NSFormatter
subclass wasn't a viable option instead of a value transformer?
Yes, because I want the user to be able to enter something like '1
1/2' but I want to store the number of 32nds (my base unit of
measure). (I also allow a type of shorthand where the user enters
<number of inches>.<number of 32nds> and my transformer deals with
this as well). We work a lot with linear dimensions here.
The other way to approach this is to add a second set of properties
-- the formatted string values of your numeric properties -- that
are dependent on the numeric ones, and bind to the string properties
instead. It's a PITA to code it all, but it puts the formatting all
in your hands.
hmm, but will my users be able to make changes to text fields that are
bound to dependent string values like that?
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?
I'll keep thinking on it. Thanks again all.
_______________________________________________
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