das kann es leider nicht sein, das wär zu einfach. i kann niemals 0 sein. Element [13] aber sehr wohl, das wird damit initialisiert, damit die Multiplikation immer klappt.
Und die Fehlermeldung sagt ja auch irgwendwas von der Multiplikation mit 0. Was doch mathematisch gesehen kein Problem ist.
die Fehlermeldung bezieht sich auf die Multiplikation, damit sind die beiden Einzelelemente schon aufgelöst worden:
aPersonendaten[13] => 0
2 => 2
0 * 2 => 0 und zwar ohne irgendwelche Zweifel.
War es ein einmaliger Fehler oder kannst du es nachvollziehen ?
Eine solche Fehlermeldung habe ich noch nie gesehen.
das erste mal das ich diesen Fehler hatte. Die Funktion läuft so seit mehr als fünf Jahren. Und nein, ich kenne sowas auch nicht, vor Allem - der Text der Fehlermeldung irritiert mich, denn bei einer Multiplikation kann es doch keinen zu großen oder zu kleinen Wert geben ... OK, zu groß vielleicht, wenn man die Grenzen einer Variablen sprengt. Aber das passiert da ganz sicher nicht.
das wird sehr sicher eine andere Fehlermeldung ergeben. Da dann ein Typemismatch vorliegt. Aber hier gibt die Fehermeldung ja ganz klar an, das beide Werte numerische sind. Und reproduzierbar ist der Fehler ja ohnehin nicht für mich. Mal eben ausprobieren ist leider nicht ...
Jan, schau mal die linke Seite an.
Wenn aPersonendaten[13] null ist, dann könnte eventuell Len(aPersonendaten) auch null sein, das heisst, man kann nicht zuweisen.
Jan hat geschrieben:Hallo Hubert,
nein, das kann es nicht sein. Das Array hat immer mindestens die Länge 2. Garantiert.
Und außerdem wäre die Fehlermeldung dann eine andere, die würde auf den Zugriff eines ungültigen Arrayinhaltes hinweisen.
Jan
Herbert hatte das vorgeschlagen und ich hatte ihm mit den gleichen Argumenten wie du widersprochen
Ich hoffte einfach auf einen anderen Ansatz.
Die logische Fehlermeldung wäre das out of range, was mir wohl beusst ist. Aber Fehlermeldungen haben gerne eine Eigendynamik, insbesondere, wenn die Ursache komplexer ist.
Jan hat geschrieben:Richtig. Aber ein Len(aArray) ergibt dann halt kein 0
Jan
OK, und was ist dort für ein Wert drinnen, bevor du den neuen Inhalt schreiben willst? Ein False eventuell? (Ja, ich weiss, da sollte auch eine andere Fehlermeldung kommen)
grundsätzlich vorgegeben sind Werte von 0 bis 3. Es gibt kein Arrayelement, das nicht einen dieser Werte hat.
In diesem Fall eine 0, das sagt ja auch die Ferhlermeldung aus. Und der Verweis auf die Codezeile gibt das auch her, denn dort wird der gespeicherte Wert mit 2 Multipliziert. Da in der Fehlermeldung steht, das 0*2 nicht geht, muß also eine 0 drin gestanden haben.
Egal ob Hotfix 35 installiert ist (Jan vielleicht bei Dir aber nicht bei den Runtimes des Kuden ?)
Es kann eigentlich nur eine Division durch 0 sein, die nicht ausreichend abgefangen wird.
Xbase++ zeigt dann auch nur 0 an, hat aber Intern einen ganz anderen Wert.
Einfach mal mit VX (wenn der so toll ist, ich habe den leider nicht und konnte den damals auch nicht installieren) testen
aPersonendaten[13] := Wert der durch 0 dividiert wird
eventuell kann VX den Wert darstellen.
vielleicht macht 64bit Probleme, wenn aPersonendaten[13] nahe 0, aber ungleich 0 ist?
(also z.B. aPersonendaten[13] := 1 - 1/3 - 2/3)
Auf welche Art wird aPersonendaten[13] gefüllt? Fehlt hier ein Runden?
die Kunden haben exakt die gleichen dll wie ich. Das läuft über die Updatefunktion automatisch.
VX würde bei einer Division durch 0 den gleichen Laufzeitfehler geben wie sonst auch. Aber hier gibt es im Code keine Division, und auch die fehelrmeldung weißt nichts darauf hin.
das kann es nicht sein. Denn wenn der Wert minimal daneben liegt kann das Ergebnis nicht zu groß oder zu klein sein. Ich habe ja hier kein Rundungsproblem sondern einen Laufzeitfehler.