I have an instance of NSTextField, e.g. someTextField, for which I will use the number formatter to limit the input to numbers only.
The problem comes with the localization combined with the specific keyboard layouts used.
I would like to allow both the, say, American and European users to enter their localized decimal separators. As you all know, in the USA that would be . and for the good part of Europe that would be , (and similar with the thousands separator, etc. but let's put that to the side for now).
So I wrote the following task:
[numberFormatter setLocale:[NSLocale currentLocale]]; for the instance of the NSNumberFormatter.
Problems occurs when the user who has , set as a decimal separator AND US keyboard layout switched on (fairly common here in Europe) presses the decimal separator key on the numeric keyboard. With the US keyboard layout on, that would give him the . as the decimal separator but at the same time it'll be ignored in the someTextField because of the localized settings system-wide. So, if you want to type 1/2 using numeric keyboard only, you'll type 0.5 (US keyboard layout) in the text field and it would be read by the system as 0 because it recognizes only , as decimal separator. This is how the program currently is working and I would like to improve it in this regard.
I would like to allow user to type in the . in the someTextField and for the system to recognize it as a decimal separator just like it would ,. This kind of behavior can be seen in Apple's own Calculator application. If you type . on the numeric keyboard it'll appear as , immediately on the screen (for all conditions as described previously).
Question is: is it possible for me to achieve this using an instance of NSNumberFormatter? If not, is it possible to set on-the-fly conversion of the numerical keyboard decimal separator key output to the decimal separator set system-wide? Or perhaps you have some other suggestions?
Thanks.
I don't have a specific answer to your question, but I'd say the right approach is not to muck about with the NSNumberFormatter at all and concentrate on trying to change the characters generated by the keyboard.
The default locale for number formatters is usually the system's default locale as set by the user in the internationalization settings. If you change that behaviour programmatically for UI elements, you are effectively telling the user "I know better than you how you want to input numbers". Arrogance of that sort on the part of the developer never gets them good marks with respect to UI design.
In fact, you could apply the same argument to remapping the dot button on the numeric keypad. How do you know that the user hasn't set US keyboard layout because it allows them to get a dot from that key? Maybe they consider it more important to be able to type the thousands separator from the keypad than the decimal separator. I'm not saying you shouldn't implement your feature, just make sure that the user has control over when it is enabled or disabled.
Anyway, you probably want to override the keyDown event on the control. More info here.
Take a look at the UITextFieldDelegate protocol. It allows your textfield to ask its delegate if it should accept a character which the user just typed. The apropriate method would be textField:shouldChangeCharactersInRange:replacementString. If the character in question is , or . just let the delegate append the properly localized decimal separator "manually" and return NO.
I'm not quite sure if this will work if the text field is set to number mode, maybe the input is being filtered before the delegate method is called - leading to the method not being called if the "wrong" separator has been filtered out previously. If so, you might want to consider leaving the text field in alphanumerical mode and use the delegate method again to filter out anything that is not numbers or separators. However, in this case you should make sure the user is not allowed to type more then one decimal separator - either ignore the surplus ones or remove the first one and accept the new one.
Related
I would like to determine the Thousand Separator used while running a VBA Code on a target machine without resolving to calling system built-in functions such as (Separator = Application.ThousandsSeparator).
I am using the following simple code using 'Format':
ThousandSeparator = Mid(Format(1000, "#,#"), 2, 1)
The above seems to work fine, and would like to confirm if this is a safe method of doing it without resorting to system calls.
I would expect the result to be a single char string in the form of , or . or ' or a Space as applicable to the locale on the machine.
Please note that I want to only use a language statement such as Format or similar (no sys calls). Also this relates to Thousands Separator not Decimal Separator. This article Using VBA to detect which decimal sign the computer is using does not help or answer my question. Thanks
Thanks in advance.
The strict answer to whether it is safe to use Format to get the thousands separator is No.
E.g. on Windows, it is possible to enter up to three characters into the Thousands Separator field in the regional settings in the control panel.
Suppose you enter asd and click OK.
If you now call Format(1000, "#,#") it will give you 1a000. That is only the first letter of your thousands separator. You have failed to retrieve it correctly.
Reading the registry:
? CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sThousand")
you get back asd in full.
To be fair, the Excel international properties do not seem to be of much help either. Application.International(xlThousandsSeparator) in this situation will return the separator originally defined in your computer's locale, not the value you've overridden it to.
Having that said, the practical answer is Yes, because it would appear (and if you happen to know for sure, please post an answer here) that there is no culture with multi-char thousand separator (even in China where scary things like 1億2345万6789 or 1億2345萬6789 exist, they happen to be represented with just one UTF-16 character), and you probably are happy to ignore the people who decided to play with their locale settings in that fashion.
In the same application I have two different instances of wxStaticText. Each displays an angular value expressed in degrees. I've tested both instances for font name and font encoding. They are the same for both. I've tested that both strings passed to SetLabel() are using the same character value, decimal 176. Yet one displays the 'degree' character (small circle, up high) as expected and the other instead displays an odd character I'm not familiar with. How can this be? Is there some other property of wxStaticText I need to test?
I can't explain what you're seeing because obviously two identical controls must behave in the same way, but I can tell you that using decimal 176 is not a good way to encode the degree sign, unless you explicitly use wxConvISO8859_1 to create the corresponding wxString.
It is better to use wxString::FromUTF8("\xc2\xb0") instead or, preferably, make sure that your source files are UTF-8 encoded and just use wxString::FromUTF8("°").
Arghhhh! Found it. I was assuming SetLabel() was wxStaticText::SetLabel(), inherited from the wxWindow base class. It's not. We have a wrapper class of our own around wxStaticText that I was not aware of. It's the wrapper class that is bollixing the string value.
Moral: When debugging unfamiliar code, don't make assumptions, step ALL THE WAY in.
i want to use comma separator to display my double value as currency value in WinRT XAML?
like
<TextBlock Text="{Binding Amount, StringFormat={}{0:C}}" />
I need to achieve this in XAML, not in C# using IValueConverter.
Thanks in advance.
Joy Rex
Sounds like something that should be delegated to be handled by the platform, not by some arbitrary format string, doesn't it? I believe this should happen automatically for users using a locale that uses commas as separators such as Polish. I don't have much recent experience with that in .NET, but perhaps a decimal type would make it work if double doesn't. Also remember that you can simply expose an AmountAsString property that is formatted by your view model since you only bind it one-way into a TextBlock anyway. Oh and otherwise - there is nothing wrong with an IValueConverter.
Just to note on this thread, the Windows.Globalization.NumberFormatting APIs are available for both currency and decimal formatting, and automatically applies the user's locale-specific or customized number formats along with currency symbol placement. The Number formatting and parsing sample shows all the variations.
I have a UITextField and I need to check, as the user types, if the text they have entered in the textfield so far matches a specific pattern.
More specifically, I need the text to match the pattern ####-##-## where # is any digit 0-9 and - is a dash (note that this is NOT a phone number or email). For example, the entry 1990-12-09 matches, 1990:12:09 does not match and 1990-12 DOES match because it has not yet violated the pattern (even though the text does not yet completely match the pattern).
How should I approach this? Ideally I would not have to hard code in a series of if statements .
The difficulty is that I want to check if the text in the textfield matches this pattern, as the user types. I don't want to just check it at the end.
I'm thinking that regular expressions are probably the way, but I'm not experienced enough at them to know if they hold the solution.
You could set the keyboard type to myTextField.keyboardType = UIKeyboardTypeNumberPad that why you are limiting the type of input.
Then this post should help answer your formatting question: UITextField format in xx-xx-xxx
i want to format number entered by user in dutch format. ie. use decimal Separator as , and thousand seperator as .
blur: function () {
Ext.util.Format.number(this.value, '000,000.00')
}
I want to format my numeric field on blur, the above code works fine, but
my requirement is to get a format like this- '000000.000,00'.
How to do this in extjs?
Quick and dirty, just set the thousandSeparator and decimalSeparator. It should work:
//Set these once, right after Ext.onReady
Ext.util.Format.thousandSeparator = '.';
Ext.util.Format.decimalSeparator = ',';
//Then this should work:
Ext.util.Format.number(12345.67, '0,000.00'); //output 12.345,67
Or even better, use the localization, so formats can be changed according to language requirement.
Side note:
The documentation wrote:
To allow specification of the formatting string using UK/US grouping characters (,) and decimal (.) for international numbers, add /i to the end. For example: 0.000,00/i
And from the comments in the source code
// The "/i" suffix allows caller to use a locale-specific formatting string.
// Clean the format string by removing all but numerals and the decimal separator.
// Then split the format string into pre and post decimal segments according to *what* the
// decimal separator is. If they are specifying "/i", they are using the local convention in the format string.
To me, it seems that it means a developer can use a specific format string "0.000,00" to format a given number, and not to mean a developer can use this specific format string to format a number into the format they want. They will still need to change the default separator setting.
Edit
Demo link: http://jsfiddle.net/chaoszcat/nbWwN/
I have this working for user entered values in a numberfield now.
As lionel pointed out, this is needed:
// set this once after Ext.onReady
Ext.util.Format.thousandSeparator = '.';
Ext.util.Format.decimalSeparator = ',';
Then change your handler to this:
blur: function(field) {
field.setRawValue(Ext.util.Format.number(field.getValue(), '0.000,00/i'));
}
You should also include this config on your numberfield:
decimalSeperator: ','
It will allow users to type in their own decimal symbols.
Working Example
Here is a working fiddle of this, using a numberfield.
A word of warning
Ext.form.field.Number does not support formatting, the blur handler I gave above will work totally fine if the user edits the field and then does not go back into it to edit it again, if he refocuses the field it will validate and try to correct the thousands markers into decimals.
If you are using this field to post data back to the server it will send it back in the format that is displayed (with thousand seperators), I don't know if that was what you were going for.
If you simply want formatted numbers you should do what you're trying to do above but with a textfield. That way it won't reconfigure your thousands as decimals.
If you want all the functionality of a numberfield (spinners, min/max validation, step increments, etc) you will have to take a look at extending the numberfield class, here is a user extension that already exists and which is almost exactly what you needed, but it includes a currency symbol, it would fairly easy to take that out.