On Mar 18, 2015, at 7:56 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk>
wrote:
> I have a text field in my GUI bound to a property of type 'double'. The text
> field does not have any explicit number formatter attached to it. When I set
> the property e.g. to 22000 then it appears in the text field as:
> 22,000
> OK, fair enough, maybe the default formatting behaviour of text fields has
> changed. The problem is that when I alter that value (but leaving it in the
> same style), so for example I change it to:
> 22,001
> then the value of my property is set to 22. In other words, the comma is not
> being parsed correctly to treat the whole text string as a number.
>
> This behaviour seems very strange and inconsistent. Is this something that
> people are familiar with? I imagine I could solve this by putting an explicit
> number formatter on every text field, but I have rather a lot of them and so
> would prefer not to do this! I'm also concerned that this is indicative of
> some subtler underlying problem that I should maybe understand rather than
> hide.
>
> Can anyone advise at all?
The short answer is: you have to use an NSNumberFormatter for correct behavior.
What is happening with your current setup is that the binding is fetching the
value of the property using KVC. KVC has to wrap scalar types like double into
objects, so the value of your property is coming through as an NSNumber. Then,
the text field binding does the equivalent of theTextField.objectValue =
theNSNumber. In the absence of a formatter, the control (or, more accurately,
its cell) has no choice but to get a string from the object by calling
-description on it.
Now, -description is not really very reliable as to how it formats the value of
the object it's called on. Apparently, -[NSNumber description] has changed
over time to include a thousands separator. My guess is that this change
occurred in 10.8. There is stuff in the 10.8 release notes for Foundation and
Core Foundation about more localization being done when strings are formatted.
The change may also be that NSNumber has started using +[NSString
localizedStringWithFormat:] rather than +[NSString stringWithFormat:] when it
constructs its description.
When editing finishes, the text field's binding uses KVC to set its new object
value on the property. The new object value is a string, since that's all the
text field knows to store edited text as. (It doesn't know it's editing a
number. That's precisely the role an NSNumberFormatter would fill.)
Eventually, KVC gets to a scalar-typed property and has to unbox the value. It
knows the property is a double, so it invokes -doubleValue on the object.
Not-so-coincidentally, NSString responds to -doubleValue. However, it's not
very sophisticated about how it parses its contents into a double. In
particular, it doesn't handle thousands separators. Also, it would probably be
confused about a string which was formatted (or typed by the user) according to
a locale that uses a character other than period ('.') as the decimal separator.
So, the round trip is broken. The proper fix is to use an NSNumberFormatter.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
