Re: Text fields bound to numerical property - commas in number
Re: Text fields bound to numerical property - commas in number
- Subject: Re: Text fields bound to numerical property - commas in number
- From: Ken Thomases <email@hidden>
- Date: Wed, 18 Mar 2015 08:32:26 -0500
On Mar 18, 2015, at 7:56 AM, Jonathan Taylor <email@hidden> 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 (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