StrToFloat -> Wahnsinn kurz bevorstehend!

[Sir Rufo]

Sage mal, stimmt das mit deiner Delphi Version "Delphi 2 Desktop"?

Vielleicht kann die noch gar nicht so große Zahlen ... :stupid:

[Teekeks]

Er sagte doch

Zitat:

Mein System: Win7 Pro deutsch, Delphi 2010 Pro.

[Hawkeye219]

Hallo easy,

lass' mich raten: du hast die Optimierung für dein Projekt eingeschaltet und beobachtest die Werte im Debugger. Falls dies so ist, schalte die Optimierung aus und führe die Versuche erneut durch.

Gruß Hawkeye

[e.asy]

Moin,

erstmal danke für die reichhaltige Reaktion. :)

Zitat:

Zitat von WoGe (Beitrag 1053689)

Da Delphi2010, änder mal String in Ansistring
Real in Double

Wenn das nicht hilft alle Punkte und Komma wegschmeissen
Nach Integer konvertieren und dann durch 100 teilen..


Gruss
wo

Ja alles Probiert... Was mich ja verwundert, ist dass der 2. Wert (12,34) immer ohne zu murren richtig konvertiert wurde.

Zitat:

Zitat von Sir Rufo (Beitrag 1053690)

Schau dir mal das da an

Damit hast du keine Sorgen mehr, sondern gleich ein paar Probleme weniger und der Zugriff ist wesentlich einfacher ;)

Alles klar, werd ich mir mal anschauen.

Zitat:

Zitat von Christian Seehase (Beitrag 1053702)

Moin Zusammen,

dass das mit dem ThousandsSeparator nicht funktioniert, ergibt, zumindest für D7 und D2006, ein Blick in die Hilfe von StrToFloat:

Zitat:

Thousand separators and currency symbols are not allowed in the string.

Vermutlich ist das bei 2010 auch so.

WTF? :shock: Du hast recht.. Wald und Bäume und so. ;)

Zitat:

Zitat von Sir Rufo (Beitrag 1053708)

Sage mal, stimmt das mit deiner Delphi Version "Delphi 2 Desktop"?

Vielleicht kann die noch gar nicht so große Zahlen ... :stupid:

Ups. :roll: Ist wohl Default-Wert hier im Forum.. Gleich mal ändern. :)

Zitat:

Zitat von Hawkeye219 (Beitrag 1053732)

Hallo easy,

lass' mich raten: du hast die Optimierung für dein Projekt eingeschaltet und beobachtest die Werte im Debugger. Falls dies so ist, schalte die Optimierung aus und führe die Versuche erneut durch.

Gruß Hawkeye

Welche Optimierung?


Sonnige Grüsse,
easy.

[e.asy]

Zitat:

Zitat von Sir Rufo (Beitrag 1053690)

Schau dir mal das da an

Damit hast du keine Sorgen mehr, sondern gleich ein paar Probleme weniger und der Zugriff ist wesentlich einfacher ;)

Ja ne, kann ich nicht benutzten, da es keine CSV-Datei ist.. Leider ein wenig fummelig das ganze.. Aber das Einlesen etc. macht auch keine Probleme halt nur das Konvertieren von "grossen" Zahlen.


Sonnige Grüsse,
easy.

[e.asy]

Zitat:

Zitat von Hawkeye219 (Beitrag 1053732)

Hallo easy,

lass' mich raten: du hast die Optimierung für dein Projekt eingeschaltet und beobachtest die Werte im Debugger. Falls dies so ist, schalte die Optimierung aus und führe die Versuche erneut durch.

Gruß Hawkeye

Ah, Optimierung gefunden... Gleiches Resultat:

Code:

                GetLocaleFormatSettings(LOCALE_SYSTEM_DEFAULT, fmtSettings);
                fmtSettings.DecimalSeparator:=',';

                dBalance:=StrToFloat('12345,67', fmtSettings);

dBalance ist und bleibt 0...

Ich verstehe es einfach nicht... :(

EDIT:

Jetzt kommt der Hammer, Wenn ich das fmsSettings.DeciamlSeparator:=... auskommentiere geht es... Natürlich habe ich das Problem, dass das ganze dann nur auf ein Wintendo mit deutscher Locale funktioniert... Oh man.. Ich geh erstmal eine rauchen....

Sonnige Grüsse,
easy.

[himitsu]

Erstmal mußt du bedenken, daß StrToFloat und Co. sprachabhängige Systemeinstellungen für "," "." usw. verwenden.

englisch
- Dezimalpunkt
- Komma als Tausendertrennzeichen

deutsch
- Dezimalkomma
- Tausenderpunkt

Dann gibt es in einigen Windows 7-Intallationen einen "Fehler", welcher dein Programm andere Werte auslesen läßt, als in der Systemsteuerung angezeigt werden.
- speziell betrifft das einige deutsche (vorinstallierte) Windows 7, wo die deutschen Einstellungen nicht überall eingetragen sind
- Delphi list dabei dann leider die englischen Einstellungen aus. obwohl der Benutzer auf deutsch eingestellt ist.
(Problem: dort sind natürlich , und . vertauscht)

Dazu gibt es schon mehrere Threads
> Lösung: Die Sprachoptionen in Windows auf Englisch stellen und dann zurück auf Deutsch,



Lösungen für dich und dein Problem, denn so oder so bleibt das Zahlenformat sprachabhängig:
- entweder die Zahlen in einem sprachabhängigen Format besorgen
- oder StrToFloat sprachunabhängig machen (PS: es gibt ein StrToFloat, welches ein FormatSettings benutzt)
[edit]

Zitat:

Ah, Optimierung gefunden...

:thumb:

Zitat:

Gleiches Resultat:

Was passiert, wenn du nicht vergißt auch noch den Tausenderpunkt zu setzen?

PS: GetLocaleFormatSettings mußt du nicht unbedingt nutzen, es reicht auch, wenn du da einfach die (nötigen) Werte direkt setzt, also die Werte, welche von der entsprechenden Funktion genutzt werden.

[e.asy]

Zitat:

Zitat von himitsu (Beitrag 1053801)

Erstmal mußt du bedenken, daß StrToFloat und Co. sprachabhängige Systemeinstellungen für "," "." usw. verwenden.

Dessen bin ich mir bewusst. Ich mein, das Zahlenformat welches ich zu verarbeiten habe ist immer Deutsch. Ich bin |-| so kurz davor nen eigenes StrToFloat zu hacken...

Zitat:

Dann gibt es in einigen Windows 7-Intallationen einen "Fehler", welcher dein Programm andere Werte auslesen läßt, als in der Systemsteuerung angezeigt werden.
- speziell betrifft das einige deutsche (vorinstallierte) Windows 7, wo die deutschen Einstellungen nicht überall eingetragen sind
- Delphi list dabei dann leider die englischen Einstellungen aus. obwohl der Benutzer auf deutsch eingestellt ist.
(Problem: dort sind natürlich , und . vertauscht)

Dazu gibt es schon mehrere Threads
> Lösung: Die Sprachoptionen in Windows auf Englisch stellen und dann zurück auf Deutsch,

Hach... Also der Debugger gibt mit nach dem GetLocaleFormatSettings richtige Werte zurück... Und wenn es daran liegen würde, dürfte er (zumindest nach meiner Logik) nicht den 2. Wert (12,34) konvertieren sondern müsste hier auch aussteigen bzw. eine 0 zurückgeben. Oder sehe ich das falsch?

Ich mein, entweder funktioniert es top oder gar nicht.. Aber so mal hü mal hott ist ja das, was mich hier um den Verstand bringt...

Zitat:

Was passiert, wenn du nicht vergißt auch noch den Tausenderpunkt zu setzen?

Zu setzen? Also wenn ich z.B. 12.345,67 konvertieren möchte schmeisst er mir ne Exception raus.

Zitat:

PS: GetLocaleFormatSettings mußt du nicht unbedingt nutzen, es reicht auch, wenn du da einfach die (nötigen) Werte direkt setzt, also die Werte, welche von der entsprechenden Funktion genutzt werden.

Hrm... Das Probiere ich doch gleich mal durch.. Ich hatte nur in einigen Examples gesehen, dass die immer mit der GetLocale.... arbeiten bevor die an den FormatSetting "rumfummeln". ;)



Sonnige Grüsse,
easy

[himitsu]

Zitat:

Zitat von e.asy (Beitrag 1053807)

Zu setzen? Also wenn ich z.B. 12.345,67 konvertieren möchte schmeisst er mir ne Exception raus.

Neee, ich meinte in deinem fmtSettings :wink:

Wenn z.B. GetLocaleFormatSettings ein englisches Format liefert
und du nur den Dezimaltrenner setzt, dann hast du zweimal das "Komma" in dieser Struktur.
Und die Exception kommt dann davon, daß der "Punkt" unbekannt ist.

Zitat:

Hrm... Das Probiere ich doch gleich mal durch.. Ich hatte nur in einigen Examples gesehen, dass die immer mit der GetLocale.... arbeiten bevor die an den FormatSetting "rumfummeln".

StrToFloat nutzt nur den DecimalSeparator und den ThousandSeparator, aus dieser Struktur ... der Rest ist also unwichtig (kann gesetzt werden oder kann eben auch sonstwas oder nix enthalten)

Über GetLocale und Co. geht man, wenn mehr von der Funktion genutzt wird (bzw. man nicht weiß was alles benutzt wird) und man nur einiges davon ändert, bzw. selber setzt. So spart man sich das Ausfüllen der restlichen Werte. :angle2:

[e.asy]

GetLocaleFormatSettings liefert immer die richtigen deutschen Einstellungen zurück. Also Decimal = ',' und Thousand = '.'...

Da mir aber momentan die Zeit fehlt, der Ursache weiter auf den Grund zu gehen, und das Format für die Zahl feststeht werde ich mir schnell ein eigenes StrToFloat hacken... Hab schon jetzt über nen halben Tag mit der Fehlersuche verbraten..

Trotzdem Danke für Eure Antworten. :)


Sonnige Grüsse,
easy