View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005579JEDI VCL00 JVCL Componentspublic2011-05-11 13:512012-06-11 17:09
ReportercguserAssigned Toobones 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionDaily / GIT 
Target VersionFixed in Version 
Summary0005579: TJvValidateEdit: Issues with DisplayFormat of dfFloat with DecimalPlaces on x64 PT
DescriptionOn a Win7 x64, with "Region and Language" set as: Format = Portuguese (implies DecimalSeparator = ','), TJvValidateEdit property GetAsFloat will be off by a factor of 1000.

TJvValidateEdit *ed = new TJvValidateEdit(this);
ed->Parent = this;
ed->DisplayFormat = dfFloat;
ed->DecimalPlaces = 3;
ed->AsFloat = 1;
if (ed->AsFloat==1000)
  ShowMessage("Error!");
Additional InformationThis seems to be rooted on a JvSafeStrToFloat call as shown below.
JvSafeStrToFloat("1,000")==1; // true on Win7 x86 PT, false on Win7 x64 PT

Using it's default extra parameter of aDecimalSepartor "solves" the problem:
JvSafeStrToFloat("1,000",DecimalSeparator)==1; // true on both Win7 x86 and x64 PT

Therefore, as a workaround for JvValidateEdit.pas, on

  function TJvCustomValidateEdit.GetAsFloat: Double;

change

    Result := JvSafeStrToFloatDef(FEditText, 0);

into

    Result := JvSafeStrToFloatDef(FEditText, 0,
      {$IFDEF RTL220_UP}FormatSettings.{$ENDIF RTL220_UP}DecimalSeparator);

This fixed (hidded?) the issue.

Just to add that this was tested on a daily SVN version from last January, sorry if it's been noticed/fixed meanwhile.
TagsNo tags attached.

Relationships

related to 0005385 resolvedobones TJvValidateEdit has a bug in DecimalSeparator handling. 
related to 0005060 resolvedobones Wrong Display and Return of Float Values by TJvValidateEdit 

Activities

cguser

2011-05-11 15:00

reporter   ~0018550

More details, this was with RS2010 with all updates applied.

cguser

2011-05-11 16:27

reporter   ~0018551

Probably the root of all this (and maybe x64 is not the real culprit),

On the Win7 x86, PT Format (system and user)
GetLocaleChar(LOCALE_SYSTEM_DEFAULT, LOCALE_SDECIMAL, DecimalSeparator)) ==
GetLocaleChar(LOCALE_USER_DEFAULT, LOCALE_SDECIMAL, DecimalSeparator)) ==
',';

On the Win7 x64, PT Format (system!=user?)
GetLocaleChar(LOCALE_SYSTEM_DEFAULT, LOCALE_SDECIMAL, DecimalSeparator)) == '.';
GetLocaleChar(LOCALE_USER_DEFAULT, LOCALE_SDECIMAL, DecimalSeparator)) == ',';

It seems that in some cases, mismatching settings of LOCALE_SYSTEM_DEFAULT and LOCALE_USER_DEFAULT may trigger this.

cguser

2011-05-11 17:26

reporter   ~0018552

I would venture that the suggested fix is accurate (while somewhat incomplete).

*All* calls from JvValidateEdit.pas into JvSafeStrToFloatDef should have the third parameter filled as

{$IFDEF RTL220_UP}FormatSettings.{$ENDIF RTL220_UP}DecimalSeparator

because *if* that argument isn't sent, _JvSafeStrToFloat will just default into using LOCALE_SYSTEM_DEFAULT.

cguser

2011-05-12 13:10

reporter   ~0018553

Last tidbit, on a W7 x86, changing the users Decimal symbol on Control Panel's Format, Additional Settings, it does change it for *both* LOCALE_SYSTEM_DEFAULT and LOCALE_USER_DEFAULT settings, while on x64, it will only affect the latter.

cguser

2011-05-13 13:08

reporter   ~0018554

We've just had in a new support issue for this very same problem on an Estonian WinXP customer. They also used "," as DecimalSeparator. This shows that the problem is not unique to Win7 x64 nor PT.

obones

2011-06-07 18:00

administrator   ~0018636

There are other issues on that subject in Mantis

obones

2012-02-24 11:58

administrator   ~0019530

Please use the latest SVN content, I believe this is fixed by the commit for issue 0005060

Issue History

Date Modified Username Field Change
2011-05-11 13:51 cguser New Issue
2011-05-11 15:00 cguser Note Added: 0018550
2011-05-11 16:27 cguser Note Added: 0018551
2011-05-11 17:26 cguser Note Added: 0018552
2011-05-12 13:10 cguser Note Added: 0018553
2011-05-13 13:08 cguser Note Added: 0018554
2011-06-07 18:00 obones Note Added: 0018636
2011-06-07 18:00 obones Status new => acknowledged
2011-06-07 18:00 obones Relationship added related to 0005385
2011-06-07 18:01 obones Relationship added related to 0005060
2012-02-24 11:58 obones Note Added: 0019530
2012-02-24 11:58 obones Status acknowledged => feedback
2012-06-11 17:09 obones Status feedback => resolved
2012-06-11 17:09 obones Resolution open => fixed
2012-06-11 17:09 obones Assigned To => obones