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.
Related
I am working on some legacy code at the moment and have come across the following:
FooString = String.Format("{0:####0.000000}", FooDouble)
My question is, is the format string here, ####0.000000 any different from simply 0.000000?
I'm trying to generalize the return type of the function that sets FooDouble and so checking to make sure I don't break existing functionality hence trying to work out what the # add to it here.
I've run a couple tests in a toy program and couldn't see how the result was any different but maybe there's something I'm missing?
From MSDN
The "#" custom format specifier serves as a digit-placeholder symbol.
If the value that is being formatted has a digit in the position where
the "#" symbol appears in the format string, that digit is copied to
the result string. Otherwise, nothing is stored in that position in
the result string.
Note that this specifier never displays a zero that
is not a significant digit, even if zero is the only digit in the
string. It will display zero only if it is a significant digit in the
number that is being displayed.
Because you use one 0 before decimal separator 0.0 - both formats should return same result.
I'm pretty new to progress and I want to ask a question.
How do I change variable (string) length in runtime?
ex.
define variable cname as char.
define variable clen as int.
cname= "".
DO cnts = 1 TO 5.
IF prc[cnts] <> "" THEN DO:
clen = clen + LENGTH(prc[cnts]).
cname = cname + prc[cnts].
END.
END.
Put cname format '???' at 1. /here change variable length/
Thanks for the reply
If the PUT statement is what you want to change, then
PUT UNFORMATTED cname.
will write the entire string out without having to worry about the length of the FORMAT phrase.
If you need something formatted, then
PUT UNFORMATTED STRING(cname, fill("X", clen)).
will do what you want. Look up the "STRING()" function in the ABL Ref docs.
In Progress 4GL all data is variable length.
This is one of the big differences between Progress and lots of other development environments. (And in my opinion a big advantage.)
Each datatype has a default format, which you can override, but that is only for display purposes.
Display format has no bearing on storage.
You can declare a field with a display format of 3 characters:
define variable x as character no-undo format "x(3)".
And then stuff 60 characters into the field. Progress will not complain.
x = "123456789012345678901234567890123456789012345678901234567890".
It is extremely common for 4gl application code to over-stuff variables and fields.
(If you then use SQL-92 to access the data you will hear much whining and gnashing of teeth from your SQL client. This is easily fixable with the "dbtool" utility.)
You change the display format when you define something:
define variable x as character no-undo format "x(30)".
or when you use it:
put x format "x(15)".
or
display x format "x(43)".
(And in many other ways -- these are just a couple of easy examples.)
Regardless of the display format the length() function will report the actual length of the data.
There is a numeric field in a legacy application that I am trying to change to alphanumeric with a field length of about 15. The field is for data entry of account information. In the code, its referenced at numerous places:
.BANK_accno = Format(Me.txtBANK, "####-##-##-##-##")
and
!BANK_accno = Format(Me.txtBANK, "####-##-##-##-##")
The Format is: ####-##-##-##-## and the Mask is ####-##-##-##-##. What I am wondering is what Format (and code) changes should I make to get the field to become alphanumeric? I tried using ##########, however that has not worked.
As BobRodes commented, you can use # to mask characters not limited to numbers. There are other options (ignore spaces, force left-to-right filling, upper/lower case).
Have a look at Format function documentation at MSDN for details. This link is for VBA but Format strings should be compatible.
Please note that you still need to validate Input, Format function is not strict about input.
I need to generate an URL string for a SSRS report (in order to link it with our CRM software). The report name is in Hebrew. When I send the URL string (with Heb) to Internet Explorer, it doesn't recognize the address because it isn't encoded with Percent-encoding (BTW, it works fine in Firefox). (Sending a URL with English only does work fine that way.)
Anyway, I tried to perform the encoding. I succeeded converting it to URI with UNICODE characters. I need to get the URI in UTF-8. For example, the letter 'י' should be converted into '%d7%99' and not to '%05%D9'.
I included a link:
A table with the codes, for your use, if needed.
I need the conversion\encoding function for 1 character. I can build the rest of the script / function for the complete string by myself.
I used a script which used the master.sys.fn_varbintohexstr function. As I said, though, the results aren't proper for IE.
the following:
SELECT master.sys.fn_varbintohexstr((CAST (N'י' AS varbinary)))
will get 0xd905, which I formatted into percent encoding. I should get 'd7 99' instead.
wrap up:
I convert an Hebrew character into URI percent encoding. I get a unicode result. I wish > to get a utf8 result.
Input = 'י'. Current output = %d9. Wanted output = %d7%99
How can I get those results?
I have had to deal with a few similar problems and there are two approaches that you may wish to consider; the first is to transform your data into HTML in the query and then render the result as HTML in the RDL, the second is to use JQuery to identify those cells with the incorrect value on the client and then transform that cell (again, using JQuery). The benefit of the second option is that if the server rendering is working on Firefox the transformation overhead doesn't get invoked. The downside is that if you are not rendering the report as HTML it won't work.
For the first option, in the select statement you would need to alter the appropriate column to produce a nvarchar value that looks like
<span style="font=yourfont;" charset="UTF-8">linkname</span>
With that string as data you then assign that to the appropriate columns (or cells, as needed)
In the RDL designer drag a placeholder for your field onto the designer and right click the placeholder and select placeholder properties then you can select to display the content as HTML.
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.