David Garratt wrote:I have a lot of swing code to update to fix this so if there was a way to use a replacement to jtextfield which could handle this it would be perfect - I realise that the jtextfield may not be at fault but if I could replace it with a class that would return a consistent formatted string that would always be represented as n,nnn.nnn it would make life just a little simpler.
David Garratt wrote:I'm not entirely sure but if I read the description correctly don't you have to specify the required display/edit format rather than just default to the regional settings.
David Garratt wrote:That's fine. However when convert the string (text) back from the field for storage in the database I get ...
David Garratt wrote:From my tests it seems that the conversion back from a string / text field to a bigdecimal is assuming that the number is formatted in us/en even when it's not and hence the swapped comma and dot which is being used correctly on screen results in the value of my decimal being wrong.
Stephan van Hulst wrote:Plain Java does this just fine. DecimalFormat can be used to parse local sensitive string representations of numbers.
The API wrote:The values are the ones constructed by BigDecimal.BigDecimal(String) for corresponding strings in locale-independent format.
Stephan van Hulst wrote:... otherwise it would absolutely make no sense to parse strings to BigDecimal using DecimalFormat...