Re: Numeric Entry and Formatting With NSNumberFormatter Won't Append Zeros
Re: Numeric Entry and Formatting With NSNumberFormatter Won't Append Zeros
- Subject: Re: Numeric Entry and Formatting With NSNumberFormatter Won't Append Zeros
- From: Philip McIntosh <email@hidden>
- Date: Tue, 27 Sep 2011 18:33:32 -0600
> Subject: Re: Numeric Entry and Formatting With NSNumberFormatter Won't
> Append Zeros
> To: Philip McIntosh <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On 23 Sep 2011, at 6:48 PM, Philip McIntosh wrote:
>
>> I have a calculation project using buttons to input numbers into a UILabel. I want it to format the numbers as they are entered to display grouping separators. It has been a struggle but so far the best I have ben able to achieve is this (I got the basic idea from a post at stackoverflow.com):
>
> A threshold question: Do I understand correctly that the only record you have of the value of your accumulator is the text contents of a label? Why? When you call
>
>> NSDecimalNumber *number = [NSDecimalNumber decimalNumberWithString:currentText];
>
> you have no control at all over how the label's text is converted to a decimal. It may or may not be lossy.
I don't follow. How could it be "lossy?" It's a string in the display (display.text), that is saved into a another string variable (currentText) so later added separators are stripped out and that string is then used to create the updated and formatted number.
> Better that you keep, as a model object, the decimal value, and avoid repeated round trips through the default parser. (You are careful to specify U.S. grouping and decimal separators for _output_, but the convenience parser you're using will use the separators from the current locale.)
>
> The rule is that you never, ever keep program state in a display object. If you _must_ go through a string (which should still be a model object, and not simply be left lying around in a label), set up an NSNumberFormatter and setGeneratesDecimalNumbers:YES, so you can get some control. You can then keep the formatter in a static variable, and reuse it for repeated conversions in both directions ˜ the round trip will be likelier to preserve your intended value.
It's not left lying around, it exists in currentText.
>
> I'm also curious to know what you intend by
>
>> currentText = [currentText stringByReplacingOccurrencesOfString:@"." withString:@"."];
>
I've done quite a bit of NSLogging in this method to see what is happening. I confirm that the char entered is a decimal and is on the end of the input string, but no zeros after that are ever detected.
Anyway, that 'replace @"." with @"." ' is a vestige from a previous failed attempt and you are right in assuming it is not required.
I have indeed set the formatter to generatesDecimalNumbers, allowedFloats, tried using floats, ints and doubles to set the NSDecimalNumber, used NSNumber instead, and also confirmed that the formatter behaves as desired if I give it a canned static string that is not built by appending a string from a button input. I have also tried it with and without setting the locale. I really don't want to use the locale anyway because I want the user to select the number format they are comfortable with without regard to what part of the world the device happens to be operating in.
I don't see anything wrong with pulling a string off a display, formatting it as a number, converting the number back into a string and redisplaying it. As I said the formatter works as expected with any number I give it starting out as a defined string (if my string is 1234567.000321 the formatter produces 1,234,567.000321). It is only when the string is built by appending digits that something goes wrong (no zeros accepted after a decimal point).
I have come up with a "work around." I simply do not invoke the NSNotification to call the updateDisplay method anymore if a decimal point is detected in the display. That way, the formatter properly handles the grouping separators in the integer part, and the string continues to be built and displayed as expected after the decimal point while preserving any previous formatting in the integer part. Any following calculations also come out correct. It works good and looks good, but hasn't helped me to understand why it didn't accept any zeros after the decimal point.
I appreciate the feedback. It's made me think.
_______________________________________________
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