After editing a number value on a German system, the value displayed is 100 times what it should be in the column, but the value displayed in the editor is correct.
I have tracked this down to the following code in ig.formatter:
// keep only e, E, -, +, . and digits
val = parseFloat(val.replace('(', '-').replace(/[^0-9\-eE\.\+]/gm, ''));
Since german uses , as the decimal separator and . as the thousands separator, applying the above code to a value such as 123,45 yields a value of 12345 while a value such as 1.234,56 yields a value of 1.23456.
Hello Karl,
I am in a similar situation..
Hi, Karl.
I have asked our engineering staff to examine this further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 139790. The next step will be for a developer to review my investigation and confirm my findings or to offer a fix, or other resolution.
I will leave this case open and update you with any new information after the review. You can also continue to send updates to this case at any time.
You can view the status of the development issue connected to this case by selecting the "Development Issues" tab when viewing this case on the web site. As far as the solution that I've proposed works for you, you can use it.
Please let me know if you need more information.
Best regards, Nikolay Alipiev
I finally tracked this down to the fact that we were using editModeText as the DataMode for the numeric editor. In this case the code is broken, but it can be resolved by changing the DataMode to Decimal.
Thank you for the feedback and for checking the things in details. I want to discuss with you some details about your case and after that if we decide this is a problem in our code I will take care to log this as a bug and therefore this to be fixed. I will be glad if you have the time to discuss this, for which thank you in advance.
The case is that the following code is executed:
The problem is that instead of period (.) in the regular expression should stay the current decimal separator, which in your case is comma (,). I will discuss this with our developers, because I think they may have some consideration on this, but as far as I see this is the problem.
But the code above is executed only if the following statement is true:
if(!n)
This is valid when the value is not a number, then it tries to execute the regular expression. This means that the column dataType is not defined or defined as a "string". If the column dataType is defined as "number" then the regular expression will not be executed and therefore the value will stay in German format. You can try if this can be applied in your scenario, because it seems an easier fix.
The other option is to set a formatter option in the column definition. There you can set a callback function, which allows you to format the value before displaying it. This means that inside you can format the value for your needs. A sample with this you can find here.
Karl, I will wait for your feedback.
Best regards, Nikolay Alipiev.
Sorry, you misunderstood the problem: the correct infragistics regional settings are being automatically picked up, so the separators are configured correctly. The problem is the parsing code that I illustrated incorrectly assumes that the period should be retained. This is incorrect.
The correct version of this code is as follows:
// Karl - Moved from below prefix = cur ? curS : (perc ? percS : 'numeric'); if (!n) { // Karl - added next 4 to replace the decimal separator with . since parseFloat is not internationalized. s = reg[prefix + 'DecimalSeparator']; if (s && (s != '.')) { val = val.replace(s, '.'); } // keep only e, E, -, +, decimal separator and digits val = parseFloat(val.replace('(', '-').replace(/[^0-9\-eE\.\+]/gm, '')); } if (isNaN(val)) { return ' '; } // Karl - Moved this up //prefix = cur ? curS : (perc ? percS : 'numeric');