Neues aus Athen - WriteFloat

[TomyN]

Hallo

Gestern bin ich über folgendes gestolpert

Wert in Inifile schreiben:

Code:

...
ini: TMemIniFile;
...
x:= 1.2;
ini.WriteFloat('Hinz','Kunz', x);
ini.UpdateFile;
...

In der selben App aus Inifile lesen

Code:

...
ini: TMemIniFile;
...
x:= ini.Readfloat('Hinz','Kunz', 1.5);
...

Folge: Fehlermeldung '1,2 ist keine gültige Zahl'

Im Inifile steht 1,2

Doku zu ReadFloat sagt:
Das Dezimalzeichen wird von der globalen System.SysUtils.FormatSettings-Variable festgelegt.

Das Schreiben geändert

Code:

...
ini: TMemIniFile;
dsl: Char;
...
dsl:= FormatSettings.Decimalseparator;
FormatSettings.Decimalseparator:= '.';
x:= 1.2;
ini.WriteFloat('Hinz','Kunz', x);
ini.UpdateFile;
...
FormatSettings.Decimalseparator:= dsl;

Und schon geht's. Jetzt steht 1.2 im IniFile, Zahlen in der App werden mit Komma angezeigt und das Einlesen klappt auch ohne Anpassung des Decimalseparators (was ich aber zur Sicherheit schon mache).

Nur so als Hinweis, falls jemand sich wundern sollte....

Tomy

[Uwe Raabe]

Ich denke eher man muss gewährleisten, dass beide Routinen mit denselben Einstellungen in FormatSettings arbeiten. Dazu gibt es auch einen Report: Add TFormatSettings parameters to TCustomIniFile read/write methods for floats and date/time values.

[DeddyH]

Zitat:

Created: 10/Mar/17 4:02 AM

Das nenne ich mal Quality Management, zumal eine mögliche Lösung schon mitgeliefert wird. Und dann wundert man sich, wenn gemeckert wird.

[Uwe Raabe]

Im Prinzip stimme ich dir zu. Allerdings handelt es sich hier um ein Feature, für das man relativ simpel selbst einen Workaround erstellen kann (z.B. einen Class Helper oder eine Ableitung von TMemIniFile). Da gibt es leider auch viele andere Issues, die man nicht so leicht selbst in den Griff kriegt.

Eigentlich bin ich ganz froh, nicht in der Position eines Product Managers zu stecken, der eine ausgewogene Triage für die im folgenden Release zu behebenden Bugs und zu implementierenden Features durchführen muss und dabei auch noch die Erwartungen der Marketingabteilung und des Managements im Rücken hat.

[TomyN]

Nun ja, lustig finde ich halt, dass beim Schreiben die aktuellen TFormatSettings verwendet werden (wie auch sonst in der App, z.B. beim FloatToStrF), beim Lesen aber eine andere Einstellung, obwohl gerade bei der Doku zu ReadFloat explizit der Hinweis auf die aktuellen Formatsettings steht.
Die Doku zu WriteFloat zeugt auch vom Qualitätmanagement

Schreibt einen booleschen Wert in eine INI-Datei.

Mit WriteFloat kann ein Gleitkommawert in eine INI-Datei geschrieben werden. Der String Section bezeichnet den Dateiabschnitt, der den betreffenden Schlüssel enthält. Der String Ident enthält den Namen des Schlüssels, dessen Wert gesetzt werden soll. Der zu schreibende Gleitkommawert wird in Value übergeben.

Nicht wundern, nur zahlen.

Tomy

[shebang]

Zitat:

Zitat von TomyN (Beitrag 1540315)

Nun ja, lustig finde ich halt, dass beim Schreiben die aktuellen TFormatSettings verwendet werden (wie auch sonst in der App, z.B. beim FloatToStrF), beim Lesen aber eine andere Einstellung, obwohl gerade bei der Doku zu ReadFloat explizit der Hinweis auf die aktuellen Formatsettings steht.

Kannst du das Problem denn in einem Minimalbeispiel nachvollziehen oder ist das bei dir in ein größeres Programm eingebettet, wo vielleicht doch an anderer Stelle die globalen FormatSettings geändert werden? Sowohl ReadFloat als auch Writefloat verwendet intern nicht anderes als System.SysUtils.StrToFloat und System.SysUtils.FloatToStr.

[Uwe Raabe]

Zitat:

Zitat von shebang (Beitrag 1540318)

Kannst du das Problem denn in einem Minimalbeispiel nachvollziehen

Also ich kann es nicht. Dieser kleine Test liefert True:

Delphi-Quellcode:

  var ini := TMemIniFile.Create(TPath.GetTempFileName);
  try
    var x:= 1.2;
    ini.WriteFloat('Hinz','Kunz', x);
    ini.UpdateFile;
    x:= ini.Readfloat('Hinz','Kunz', 1.5);
    Writeln(SameValue(x, 1.2).ToString(TUseBoolStrs.True));
  finally
    ini.Free;
  end;

Die Datei hat dann diesen Inhalt:

Code:

[Hinz]
Kunz=1,2

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1540310)

relativ simpel

Permanent an einem nicht threadsicherem programmglobalem Setting rumzupfuschen, würde ich nicht als "Lösung" ansehen.

So lange die INI nur auf dem selben Computer / im selben Windosaccount läuft unr niemals an den Spracheinstellungen was verändert wird, mag es funktioieren,
aber ansonsten ist es ein Fehlverhalten / Bug der INI-Komponente, wenn sie standardmäig nicht "sprachunabhängig" arbeitet.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1540321)

Permanent an einem nicht threadsicherem programmglobalem Setting rumzupfuschen, würde ich nicht als "Lösung" ansehen.

Das hatte ich in diesem Zusammenhang ja auch gar nicht als solche bezeichnet:

Zitat:

Zitat von Uwe Raabe (Beitrag 1540310)

für das man relativ simpel selbst einen Workaround erstellen kann (z.B. einen Class Helper oder eine Ableitung von TMemIniFile).

Der Class Helper bekommt die überladenen Methoden, während die Ableitung im Wesentlichen auf deiner Lösung in dem QP-Kommentar basiert.

[Redeemer]

Ich fand die Verwendung von FormatSettings bei INIs so ein absolutes Unding, dass ich einfach zwischen Double/TDateTime und Int64 caste. Dafür habe ich mir einen Class Helper für TCustomIniFile geschrieben. Ist dann zwar nicht mehr lesbar, ist mir aber egal.