Stringreplace bugt!

Weil 2.500 2.5 ist. Die Nullen werden schon entfernt, wenn du die Zahl eingibst, also nach Zeile 1 sind sie schon weg ^^. Alles andere wäre mathematischer Unsinn.

2.50000000 = 2.5
2.501 = 2.501

Grundschulmathe! Wozu genau brauchst du denn diese Nullen? Aus dieser "Funktion" lässt sich das nicht erkennen.

Zitat

mit String(2.500) kann man doch eigentlich erwarten, dass dann "2.500" draus wird und nicht "2.5"..

Wie denn nur? So etwas wie 2.500 gibt es nicht, was soll das sein? Das ist und bleibt 2.5, da kannst du so viele Nullen dahinterpacken wie du willst ^^.

Zitat

Aber schön dass du so unhöflich bist, gibt andere die das wohl deutlicher schreiben können und sagen können WO genau der Fehler liegt, denn dieser Fehler liegt meineswissens bei Autoit selber. Eine eingegebene Zahl soll nämlich so genommen werden wie sie ist.

Richtet sich nach den allgmeinen Regeln der Mathematik. Ist kein Bug, sondern ein Verständnisproblem deinerseites.

Warum übergibst du die "Zahlen" nicht einfach als String? Die kannst du dann bei Bedarf per Number() als Zahl erhalten.

Alternativ kannst du auch mit

StringFormat("%.3f", 2.5)

die Zahl in einen String umwandeln und dabei festlegen, dass genau 3 Nachkommastellen angezeigt werden sollen.

Wo soll das denn bitte ein Bug sein? Der Fehler liegt also bei AutoIt!? Es mag einfach sein den Fehler auf die Entwickler der Programmiersprache zu schieben, aber erstens hilft dir das nicht bei der Fehlersuche und zweitens ist das wirklich unwahrscheinlich, dass du einen Bug in einer der am meisten verwendeten Funktionen (die schon seit Jahren in dieser Form existiert) als erster entdeckt hast.

Das Problem liegt bei deinem fehlerhaften Verständnis dieser Programmiersprache. AutoIt stammt, ob du es glaubst oder nicht, von einem englischsprachigen Entwickler namens Jonathan Bennet (abgesehen davon verwenden die meisten Programmiersprachen englische Sprachstandards). Im Zahlensystem seiner Sprache werden eben Punkte zur Trennung der beiden Ziffernfolgen bei Dezimalbrüchen verwendet. Deine "2.500" werden von AutoIt also nicht als "2500" sondern als "2,500" dem Dezimalbruch (25/10) interpretiert. Da du das nicht in Stringform deklarierst, sondern als Zahlenwert kürzt AutoIt die überflüssigen Nullen die, wie minx dir schon oft genug erklärt hat, den Wert kein bisschen beeinflussen. Ergo: "2.500" -> "2.5" was nach unserem System "2,5" wäre.

Wenn du jetzt mit StringReplace aus "2.5" alle Punkte rausnimmst, was bekommst du dann? Richtig, "25". Wo ist jetzt der Bug? Dieses Verhalten ist absolut natürlich und sinnvoll.
Freu dich doch einfach darüber, dass AutoIt so lieb ist und deine seltsame Idee eine String-Funktion auf einen Zahlenwert anzuwenden dank Variant Datentyp und sinnvoller Datentypkonvertierung toleriert.

Edit: Hier noch mal in der Übersicht zum nachlesen.

Aus gelöst setzen wäre noch ne Idee

Zitat von Texos

Ich programmiere schon seit 9 Jahren und du willst mir etwas über Punkte, Kommata oder sonstige Zeichen erklären?

Ich vermute in diesen 9 Jahren hast du vor allem nur dynamisch typisierende Sprachen programmiert.
Im Normalfall übergibt man beim Programmieren einer Funktion welche einen String als Eingabe erwartet keinen Float-Wert.
Sowas ist halt nur in dynamisch typisierenden Sprachen möglich.
Das vereinfacht zwar vieles führt aber zu solchen Phänomenen wie du es hier beschreibst weswegen man sich dennoch immer im Hinterkopf behalten muss was für Datentypen man denn implizit eigentlich wirklich verwendet und wie sie implizit gecastet werden:

MsgBox(0, "", 'Stringreplace(2.500, ".", ""): ' & @TAB & Stringreplace(2.500, ".", "") & @CRLF & 'Stringreplace("2.500", ".", ""): ' & @TAB & Stringreplace("2.500", ".", ""))

Zitat

Ich programmiere schon seit 9 Jahren und du willst mir etwas über Punkte, Kommata oder sonstige Zeichen erklären?

Was wieder mal deutlich meine These beweist, dass ein Vollspaten, ob Programmierer oder nicht, so dermaßen von sich überzeugt ist, dass er, statt das "Problem" zu debuggen bzw. den Fehler selbstständig zu finden, lieber quiekend und heulend davon ausgeht, dass immer nur andere Fehler machen.
90° bücken, die Arschbacken auseinanderreißen und heulend darauf warten, dass Mama oder Tante Frieda wie in den letzten 20 Jahren Puderzucker reinblasen....und da wundern sich einige, dass Zitate wie :" Völlige Fehlerfreiheit für Software, die eine gewisse Komplexitätsgrenze überschreitet, ist weder erreichbar noch nachweisbar." von genau DIESEN Personen auch noch unisono abgenickt werden! Und der Rest der Menschheit nickt mit...

AspirinJunkie, und wenn du mir jetzt damit kommen willst, dass die "Jugend" das garnicht können kann, weil sie ebensolche "Techniken" (debuggen bzw. Fehler finden) nicht beigebracht bekommt, dann gebe ich dir Recht!
Wir haben uns dermassen daran gewöhnt, dass "reale" gefertigte Produkte wie Fernseher, Handys, Autos, Brot oder Suppenschüsseln nur völlig fehlerfrei akzeptiert werden, während Software per se schon eine Fehlerbehaftung implizit unterstellt wird.
Wenn heute auf der Autobahm 30-40 Autos ineinanderrasen, dann hat das nicht daran gelegen dass die Fahrer mit völlig überhöhter Geschwindigkeit weit jenseits ihres eigenen Reaktionsvermögens unterwegs waren, sondern daran, dass der Abstandswarner nicht funktioniert hat, oder das automatische Bremssystem. In jedem Fall MUSS es ein technisches Problem gewesen sein, denn kein Mensch wäre so blöde im dichten Nebel mit 160km/h 30-40m hinter dem vorrausfahrenden herzudonnern.......oder?

Zitat

weswegen man sich dennoch immer im Hinterkopf behalten muss was für Datentypen man denn implizit eigentlich wirklich verwendet und wie sie implizit gecastet werden:

selbst wenn der "Hinterkopf" völlig leer ist, hat man die Möglichkeit, mit programmiertechnischen Mitteln den "Fehler" abzufangen bzw. zu lokalisieren.

If VarGetType($xPos)='Double' blablub

ach...

BTW: Mit der deutschen Sprache steht er auch auf Kriegsfuß