If you set custom separator you will need to parse to parse the value manually. This works for normal editing out of the box, because there you have different RadNumericTextBox that have it's own parsing capabilities. However in the batch the value are sent from browser to server as string. (And you don't have Decimal Type in JS), so we try to parse them using the Decimal.Parsе, using the current culture, and if it fails you get the string directly.
Can I know in which version the bug is fixed for character comma or dot? I am using the latest version 2015.1.225.45. In version 2015.1.225.45, if I set numeric decimal and group separator as comma or point, it gets the decimal in string format correctly , but I need to parse the string value manually to decimal. Will the latest version get good decimal object without parsing? In version 2015.1.225.45, if I set numeric decimal and group separator other than character comma or point, we get incorrect decimal object, we can never parse. Will the latest version get good string object so that I can parse or if it doesn't get good decimal object or string format , can you confirm that we can never use other characters other than comma or point?
In custom number format, for all characters as group or decimal separator, except characters "," and ".", GridBatchEditingEventArgument receives incorrect decimal value without separators. So we can't even parse this incorrect decimal value.
I have various bugs in GridNumericColumnEditor in Telerik version 2014.1.403.45. The GridBatchEditingEventArgument newValues of GridNumericColumnEditor always returns decimal value as string as it is displayed in grid with its custom format. It never returns a decimal object. For example, if I type 1234,56 in French culture, it returns "1234,56" as string in newValues. Normally it should return only decimal object without any format in newValues. In some cases, it returns wrong decimal objects. For example if my decimal separator is "a" and group separator is "b" and if I type 1234a56, it returns decimal object 123456 instead of 1234.56. Can you fix it so that the newValues of GridBatchEditingEventArgument returns correct decimal objects independant of culture and custom number format? Can you say me when will this bug be fixed because we have a client waiting for the correction. Can you make it as soon as possible?