Solved

Inconsistent number formats using European regional setting

Posted on 2013-01-23
8
765 Views
Last Modified: 2013-02-05
My Visual Basic 2008 application, using Crystal Reports for reporting, has a new customer in Poland. The Polish regional setting in Windows lays out numbers with a space for the thousands separator, and a comma for the decimal separator (instead of the US English standard of comma and dot, respectively). For example, what with the US English setting displays as 1,234.56 displays with the Polish setting as 1 234,56   I'm developing and compiling the software on my US English machine.

For the most part, my CR reports display the numbers correctly using the machine's regional settings. However, I have a few numbers that for some reason are displaying using US English settings. In one report, all the detail values use the machine settings, while the sums in the report footer use US English. In another report, there are three fields that show up with US English, and dozens of others that use the machine settings.

I've looked thoroughly through the number formatting options for each field, and I don't see anything different. I'm not using the decimal separator or thousands separator custom formatting options, though I am using a custom setting for the number of decimals on almost all these fields (most are conditional, using a parameter sent to the report; a few are set to an explicit 3 decimals), both those working correctly and those not.

Any ideas on why the numbers are displayed inconsistently, and how to resolve it (short of changing every number field to use passed parameters for the separators rather than the machine settings)?
0
Comment
Question by:ElrondCT
  • 5
  • 3
8 Comments
 
LVL 20

Author Comment

by:ElrondCT
ID: 38813201
Update: With more testing, I've found a couple of situations that lead to this result. Setting the number format option for negatives to None (or property NegativeType to crNotNegative), or setting DisplayReverseSign (option Reverse Sign for Display) to True, causes the number format to be automatically US English. Oddly, though, I'm running into a roach motel situation: changing the setting back doesn't cause the number to go back to the regional settings format.

It may be that recreating all the fields involved will solve my problem--except for the fields that actually do have to have the negative turned off. I may be able to take care of that with a formula field to do the work, but one of my formula fields is also misbehaving with the number format, so I don't yet know if that's a viable solution.

Any thoughts are welcomed.
0
 
LVL 100

Expert Comment

by:mlmcc
ID: 38817015
Have you tried setting the regional setting to Polish?

mlmcc
0
 
LVL 20

Author Comment

by:ElrondCT
ID: 38820015
It's not a good option to change the regional setting on the development computer before compiling the software; the software is going to a number of different countries, and I don't want to have a different build for each one. This particular client is actually in eight different European countries, and almost every one has a different format. (It's amazing how many variations there are.) I don't want to tell them they have to use eight different installation files for my software. Windows is designed to take care of this so you don't have to recompile for each location; there's just this minor hiccup in CR. (There's a separate issue for dates in CR; I found I had to use conditional formatting for each date field, which is tedious.)
0
How Do You Stack Up Against Your Peers?

With today’s modern enterprise so dependent on digital infrastructures, the impact of major incidents has increased dramatically. Grab the report now to gain insight into how your organization ranks against your peers and learn best-in-class strategies to resolve incidents.

 
LVL 100

Expert Comment

by:mlmcc
ID: 38821258
Crystal is supposed to handle it by using the regiional setting for numbers and dates as the defaults.

DO you have any default formats set for fields in the REPORT OPTIONS?

mlmcc
0
 
LVL 20

Author Comment

by:ElrondCT
ID: 38821430
All of the reports I checked have a number format of "Custom Style," which is set for 2 decimals, rounding to 2 places, leading minus sign for negative, thousands separator and leading zero checked, and decimal and thousands separators are the standard for US English (dot and comma, respectively). I'm not sure why it's set as "Custom."

However, I will point out that most numbers are displaying correctly; it's just a small few (that have had the sign tampered with) that are making a mess. They are all on the same report, sometimes the same line.
0
 
LVL 100

Expert Comment

by:mlmcc
ID: 38821483
Under FILE --> OPTIONS there is a tab to set the default formats for new fields placed on the report.  Any special formats set that might be controlling the fields in question?

mlmcc
0
 
LVL 20

Accepted Solution

by:
ElrondCT earned 0 total points
ID: 38835902
Everything is fine with a new field. It's only when I set the special formatting for negative numbers that the format gets locked into US English mode. (And what I find particularly bizarre is that undoing the special formatting doesn't undo the locked US English format.)

Since I have a small number of fields that are affected, I think the most practical solution for me at this point is to pass through parameters for the thousands and decimal separators, and use those to custom format those few fields. It's a nuisance, but it works, and there are probably not more than a dozen fields that need to be altered.
0
 
LVL 20

Author Closing Comment

by:ElrondCT
ID: 38854330
No answer to why the problem was happening. This is my workaround.
0

Featured Post

How Do You Stack Up Against Your Peers?

With today’s modern enterprise so dependent on digital infrastructures, the impact of major incidents has increased dramatically. Grab the report now to gain insight into how your organization ranks against your peers and learn best-in-class strategies to resolve incidents.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In my previous two articles we discussed Binary Serialization (http://www.experts-exchange.com/A_4362.html) and XML Serialization (http://www.experts-exchange.com/A_4425.html). In this article we will try to know more about SOAP (Simple Object Acces…
For those of you who don't follow the news, or just happen to live under rocks, Microsoft Research released a beta SDK (http://www.microsoft.com/en-us/download/details.aspx?id=27876) for the Xbox 360 Kinect. If you don't know what a Kinect is (http:…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

792 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question