Floattostr wandelt Komma in #0

[ioster]

Ich habe eine Anwendung in Bearbeitung, die ich vor ein paar Jahren geschrieben habe. Dabei handelt es sich um eine Preiskalkulation, die mit einem Formelparser auch Feldinhalte mittels Formeln errechnen kann. Aufgemacht habe ich das Projekt, weil Änderungen gewünscht werden, die den eigentlichen Kern der Berechnungen gar nicht betreffen.

Nun habe ich aber das Problem, das an einer Stelle, an der Feldwerte mit SysUtils.FloatToStr in eine Zeichenkette umgewandelt werden, um in eine Formel einen Platzhalter ersetzen zu können, plötzlich merkwürdige Ergebnisse herauskommen.

Aus 4,5887305339 macht die Funktion '4'#0'58873053386861'. Das dabei Berechnungen auf die Bretter gehen, dürfte klar sein. Nur warum wird aus einem Komma "#0"?

Mit der Entwicklungsumgebung DELPHI 2007 arbeite ich tagtäglich. Komponenten sind auch nicht hinzugekommen. Der Wert wird in einer KbmMemtable Version 7.18.00 gespeichert.

Ich muss allerdings dazu sagen, dass ich auf dem PC .NET Framework 4.0 installieren musste, weil es mein Virenscanner von Kasperky verlangte. Kann das die Delphi-Routinen beeinflussen? Ich arbeite schon etliche Jahre mit DELPHI, habe so etwas aber auch noch nicht gesehen.

Gruß
Ingo

[mkinzler]

Ich vermute mal das ist ein Unicodeproblem. Ändere sden Typ mal auf AnsiString

[Der schöne Günther]

Verstehe nicht was Unicode damit zu tun haben soll. Ich hätte eigentlich gedacht dass du entweder deine Anwendungs-eigenen FormatSettings.DecimalSeparator umgestellt hast (wohl kaum, aber prüfe das doch mal), oder jemand deinen windows-weiten Decimalseparator.

[mkinzler]

#0 in Strings weissen im Allgemeinen auf Unicode hin.

[DeddyH]

Mit Delphi 2007? Das müsste dann aber irgendwas Selbstgestricktes sein.

[ioster]

Zitat:

Zitat von DeddyH (Beitrag 1297803)

Mit Delphi 2007? Das müsste dann aber irgendwas Selbstgestricktes sein.

Nein - Selbstgestricktes in Richtung Unicode ist nicht dabei. Ich habe jetzt den numerischen Wert direkt in die Funktion gegeben und einen korrekten String zurückerhalten. Als nächstes versuche ich es einmal mit einem Zugriff auf eine reelle Tabelle. Dann kann "nur" noch die Memtable das Problem erzeugen. Die Sourcen können natürlich inzwischen Schalter für Unicode haben. Das entzieht sich aber meiner Kenntnis.

Danke schon 'mal für die schnellen Antworten und Tipps.

Gruß
Ingo

[Popov]

Zitat:

Aus 4,5887305339 macht die Funktion '4'#0'58873053386861'. Das dabei Berechnungen auf die Bretter gehen, dürfte klar sein. Nur warum wird aus einem Komma "#0"?

Warum gehen Berechnungen auf die Bretter, weil du mit FloatToStr einen String generierst? Ob im String die Zahl ob die erste Zeile von Pippi Langstrumpf Lied steht, sollte dem Programm doch egal sein, denn du rechnest ja mit der Zahl und nicht mit dem String. Andersherum wäre es kritisch.

Aber egal. Ich weiß nicht warum, aber anscheinend steht irgendwo in den Einstellung ein #0 als Dezimaltzrennzeichen eingetragen.

Wenn du entscheiden willst was das Dezimaltrennzeichen sein soll, dann musst du es der Formel sagen. Hier mal aus dem Kopf:

Delphi-Quellcode:

var
  d: Double;
  fs: TFormatSettings;
  s: string;
begin
  d := 4.5887305339;
  fs.DecimalSeparator := ',';
  s := FloatToStr(d, fs);
  ShowMessage(s);

Nun weiß Delphi was gewünscht ist.

[himitsu]

Ich vermute auch eher, daß dort das globale FormatSettings futsch ist. -> "jemand" hat #0 als Dezimaltrenner deklariert
* Tausendertrenner = #0 geht, denn das besagt, daß es keinen Tausendertrenner gibt (Dezimaltrenner gibt es aber immer)
* oder jemand übergibt ein defektes FormatSettings via Parameter an FloatToStr.

[ioster]

Zitat:

Zitat von Popov (Beitrag 1297805)

Zitat:

Aus 4,5887305339 macht die Funktion '4'#0'58873053386861'. Das dabei Berechnungen auf die Bretter gehen, dürfte klar sein. Nur warum wird aus einem Komma "#0"?

Warum gehen Berechnungen auf die Bretter, weil du mit FloatToStr einen String generierst? Ob im String die Zahl ob die erste Zeile von Pippi Langstrumpf Lied steht, sollte dem Programm doch egal sein, denn du rechnest ja mit der Zahl und nicht mit dem String. Andersherum wäre es kritisch.

Die Berechnungen gehen auf die Bretter, weil die Werte in fertige Formeln eingesetzt werden also

"[Fertigungskosten] + [Materialzuschlag]" => "10 + 4'#0'58873053386861"

Dieser String wird dann in einen Formelparser weitergereicht, der dann den numerischen Wert zurückgibt.

Gruß
Ingo

[Popov]

Verstehe. Aber wenn du mit einem Parser arbeitest, ist es um so wichtiger mit TFormatSettings zu arbeiten, denn sonst arbeitet das Programm nur zufällig richtig. Denn wenn dein Parser ein Komma "," als Dezimaltrennzeichen erwartet und plötzlich arbeitet ein Schweizer damit (da ist es üblich Punkt "." als Trennzeichen zu nehmen), gibt es Probleme.