Does StringToFloat / StringToFloatDef change "," to "." ??

[wp]

When you prefer the dot, why don't you change the language settings of your OS accordingly? Then all programs everything would be fine for you, you could keep the DefaultSettings.DecimalSeparator and avoid confusion of your users.

In my opinion, a gui program must stick to the language settings of the system. When it has scripting capabilities it must use the decimal point inside the script, otherwise the script would be locale-dependent. Script parameters entered in the gui must use the Formatsettings decimalseparator, in my opinion it should however be tolerant in case of separtors of the "other" kind. But anyway, it must convert to do..inserted in the script.

I agree that all this is a mess. But when you change DefaultSettings you add to this mess.

I doubt that writers of software which forces the user to enter floats with a decimal point are aware of this problem.

[Peter H]

When you prefer the dot, why don't you change the language settings of your OS accordingly? Then all programs everything would be fine for you, you could keep the DefaultSettings.DecimalSeparator and avoid confusion of your users.
that writers of software which forces the user to enter floats with a decimal point are aware of this problem.

I use "normal" Software also of course with finances and in correspondence, I use comma.
I write programs mainly for own use, I am not in job anymore. However if people work in industry using software and measuring instruments, they are used that they must use "." often and are not confused.
The program accepts both, comma and point as input and it outputs point only, which is necessary to generate tables for SPICE, so where is a problem?

[wp]

I agree with very special software. But even these users will have problems when they copy their measurement data with decimal points to Excel requiring a decimal comma to create a chart for a Powerpoint presentation, and blame Microsoft that the chart axis is suddenly labelel with "Jan 23" instead of "1.23"

[Ally]

Hello,

my component DecimalNumberEdit is a component for entering numbers.
The component is available in the "Online Package Manager" under "RhsPack".

The input field only accepts valid numbers that can be limited using the Matrix property.
The component provides four new properties.

1. Matrix (string)
   The number format is defined via this property.

   Examples:
   99.99 Allows you to enter values in the range from 0 to 99.99 with two decimal places.
   -50.9 Allows you to enter values in the range from -50.9 to 50.9 with one decimal place.
   250.000 Allows you to enter values in the range from 0 to 250 with three decimal places.
   -500 Allows you to enter values in the range from -500 to 500 without decimal places.


2. Value (Extended)
   Returns the extended value of the entered value.
   This value can be evaluated during input and represents the value currently entered in the input field.


3. EnterKey (Boolean)
   Allows the Enter key to be used in the same way as the Tab key.


4. WarningTone (Boolean)
   Outputs a warning tone when illegal entries are made.


Under Windows the localization settings such as the DecimalSeparator is automatically adopted.
Should the project also use the localization settings under Linux / Unix,
you should add the entry clocale to the project uses.

Example:

uses
  {$IFDEF UNIX}{$IFNDEF DARWIN}
   clocale, // Sets the localization settings (number, date and time formats)
  {$ENDIF}{$ENDIF}
  SysUtils, Forms, ......


greetings Roland

[Peter H]

Does it support scientific format, e.g. -1.23e-6 ?
BTW, on output I would appreciate engineering format for output, that means the exponent is always a multiple of 3.

[winni]

Hello,

my component DecimalNumberEdit is a component for entering numbers.
The component is available in the "Online Package Manager" under "RhsPack".

The input field only accepts valid numbers that can be limited using the Matrix property.
The component provides four new properties.

Hi!

Does your  component care about strings which are entered by paste?

This is heavily used in the office.

Winni
 

[marcov]

That  is not an argument.
Keep the representation of data and the data for computing separat.

This _is_ about input validation. And over here, both Dutch (which uses decimalsep=',' and thousands ='.') and UK/US versions are in use of both Windows and Office.  Sometimes even within one company (e.g. Dutch for most, but engineers and IT using UK or US etc). Or Office and OS locales that don't match. So that you get non locale encodings in exported Excel CSV files.

And user education is hard, specially when they are customers. 

I agree with WP: be extremely reluctant to change default encoding. It is almost never a good idea.

<sarcastic on> There should be a GuessTryStrToFloat in FPC </> :-)

In my libs it is called "ConvertSingleLocaleIndependent". But while it seems to works fine for me with a mix of European mainland (Dutch,Danish,German,French,Italian) locales and US/UK ones, I've been reluctant to put in in e.g. strutils because it might not work for any arbitrary locale.

Also which locales to preload, and on *nix the situation is more complicated because it doesn't have getlocaleformatsettings().   It is just hard to do right in the general case, but if you know a limited number of locales in play, it seems to be fine.

[Peter H]

be extremely reluctant to default encoding. It is almost never a good idea.

If Writeln and so on is used, is there another way?
And because functions like Str() (used in the DMath unit) ignore the Defaultsettings "en" or "us" conventions are in many cases the easiest and securest way.
It is just lingua franca in the world.
Or think about "CSV" comma separated values, a format that is still widely in use.

[wp]

If Writeln and so on is used, is there another way?

Not directly. Of course, you can use the SysUtils conversion routine (FloatToStr etc) which take care of locale.

You should be aware that WriteLn and Str are ancient routines written when nobody thought of the possibility that once computers would be found in every household, and when the only computer language was English, and therefore, nobody thought of localization then.

And because functions like Str() (used in the DMath unit) ignore the Defaultsettings "en" or "us" conventions are in many cases the easiest and securest way.
It is just lingua franca in the world.

This is correct for data files, or maybe commandline programs. But definitely wrong for gui programs, at least those which leave your own computer and can be used by other people.

[Ally]

@Peter H
No, only numbers with a decimal separator.

@winni
Yes. The validity is also checked when inserting.

[marcov]

be extremely reluctant to default encoding. It is almost never a good idea.

If Writeln and so on is used, is there another way?

Writeln's floating point output is rarely used in applications, since it goes to exponential notation too quickly.

And because functions like Str() (used in the DMath unit) ignore the Defaultsettings "en" or "us" conventions are in many cases the easiest and securest way.

Then have DMath fixed. Buggy existing code is no excuse to make everything buggy then.

For a limited local set of scripts, it is of course ok, and I'd be lying if I would say I never would for limited own use scripts.

But as a general rule? Not even close. Don't let a little tech bubble misguide you. There is a real world out there.

It is just lingua franca in the world.

And the Frankish language is Dutch (or alternately Afrikaans or Luxembourgish). But certainly not English :-) (*)

Or think about "CSV" comma separated values, a format that is still widely in use.

Everybody says "CSV", but rarely ever means that in the CSV standardized way. Rather, in such informal talk whatever Excel outputs is what is considered "CSV", and for locales with comma as decimal separators, Excel exports files semicolons as field separator.

This ambiguity btw makes it extremely hard to have e.g. a "csv" file export from a webpage and have it open reliably in Excel (or at least it was 15 years ago, when I last tried).

(*) Dutch Linguist joke, please do not take seriously.