• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Regional number formats - jtextfield advice.  RSS feed

 
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I have my application running on a site a different users have different regional settings for Windows so that when a value is calculated (mostly as a decimal) and then assigned to a jtextfield it respects the windows formatting format so I might see

4,567.000
Or
4.567,000

That's fine. However when convert the string (text) back from the field for storage in the database I get

4.567 instead of 4567.00 as the dot is being interpreted as a decimal place and not a thousand separator.

Sorry for lack of source code at this point as I'm in a hospital bed typing on my mobile.

Assuming I have a set and get method to get a decimal from a database and I want to both set and read the jtextfield.gettext() in a manner which can understand the context of comma and dot according to regional settings - how should I be doing this ?

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.

Many thanks

Dave

 
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Isn't JFormattedTextField the class you're looking for?
 
David Garratt
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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. Then I'm not sure if I would be any better determining the value of it.

Sorry if I've misread it.

Dave
 
David Garratt
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To clarify using pseudo code

Decimal myval = 12345.678

Jtextfield mytextfield.settext(myval.toString)

On screen displayed as 12.345,678 due to regional settings

Decimal exitVal = new Decimal (mytextfield.gettext());

Actual value of exitVal is now 12.345

If I swap out text field for formatted text field are you suggesting that I set the display format to us format even if the users normally used to seeing Hungarian for example ?

Sorry for rough and ready pseudo code - been awake in hospital ward all night.
 
Marshal
Posts: 64179
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would suggest you use a Locale object to create the display.Unfortunately, there isn't a BigDecimal constructor taking a Locale as a parameter.
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Oh, you do want to default to the regional settings. But Java code already does that, in Java terms. I think it's possible that "regional settings" means, to you, something which Windows does. But that isn't what Java does.

Example: my Windows machine is set so that it formats dates like "2019-05-14" because I prefer to format dates that way. But Java sees that I'm in Canada so it formats dates by default like "14/05/19" (because somebody told it we use DD/MM/YY here, which is mostly false).

As far as I know there's no way for Java to use the Windows settings. You might be able to use JNI to get those settings and then you could modify your code to use that data as defaults throughout, but that would be a lot of work.
 
David Garratt
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I have done for a quick global fix is to use Locale.setdefault to ensure that I have a consistent us/en format throughout the application - at least until I have a better solution.
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe you have some users in the US (where they write 456.00) and some in Germany (where they write 456,00) -- or something like that? I would have thought that Java would apply those differences consistently and you wouldn't run into the problem you're describing. So maybe it's this "Decimal" class which has some built-in decimal formatting rules rather than using the Java locale defaults?
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

David Garratt wrote:That's fine. However when convert the string (text) back from the field for storage in the database I get ...



Or maybe it's this interface which is the source of the problem. It might be that the database isn't designed to use the Java locale defaults for decimal formatting. But really that shouldn't matter. Because you shouldn't be letting the database convert string values to decimal values. It would be better to do that yourself, using the Java default locale rules, and then use a PreparedStatement and its setBigDecimal method to pass the number to the JDBC driver.

And in this case the JTextField is a red herring, because it's just a place where you store a String value for the user to see.
 
David Garratt
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

My above fix it a temporary measure to help overcome a inconsistent data problem for now but will need more work.

Dave
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Yeah... when I look at the documentation for new BigDecimal(String) it doesn't say anything about the decimal point being locale-sensitive. Bummer.
 
David Garratt
Ranch Hand
Posts: 242
Eclipse IDE Mac Safari
 
Saloon Keeper
Posts: 10136
214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Plain Java does this just fine. DecimalFormat can be used to parse local sensitive string representations of numbers.
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Plain Java does this just fine. DecimalFormat can be used to parse local sensitive string representations of numbers.



I was going to say "But, but, DecimalFormat.parse() returns a double value, then you have to wrangle it back into a BigDecimal value." However I looked at the documentation and I see that DecimalFormat.parse() can be made to return a BigDecimal value if you use it right. Hooray!

But then I read the documentation some more and noticed that it said

The API wrote:The values are the ones constructed by BigDecimal.BigDecimal(String) for corresponding strings in locale-independent format.



So, not hooray after all. Looks like we're left with wrangling the double value into a BigDecimal. However I haven't written a little test program to see if all that documentation-interpreting is correct...
 
Stephan van Hulst
Saloon Keeper
Posts: 10136
214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think what they mean by that is just that the same BigDecimal value is returned as the one that is returned by new BigDecimal(string) if string was the locale independent version of the actual input string. It's a bit confusing the way they put it, but otherwise it would absolutely make no sense to parse strings to BigDecimal using DecimalFormat.

DecimalFormat should work just fine.
 
Paul Clapham
Sheriff
Posts: 24380
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:... otherwise it would absolutely make no sense to parse strings to BigDecimal using DecimalFormat...



Okay, I'm mostly convinced by that point of view.    I might even get around to writing a little test code.
 
Montana has cold dark nights. Perfect for the heat from incandescent light. Tiny ad:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!