Solved

Inconsistent number formats using European regional setting

Posted on 2013-01-23
8
776 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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 101

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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 101

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 101

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

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

Today I had a very interesting conundrum that had to get solved quickly. Needless to say, it wasn't resolved quickly because when we needed it we were very rushed, but as soon as the conference call was over and I took a step back I saw the correct …
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
If you’ve ever visited a web page and noticed a cool font that you really liked the look of, but couldn’t figure out which font it was so that you could use it for your own work, then this video is for you! In this Micro Tutorial, you'll learn yo…

623 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