Danke für das Aufzeigen des Bugs. Solche Sachen können recht
nervig sein, wenn sie in einem größeren Programm versteckt sind. ....
Hier mal ein kleiner Code zum Eingrenzen des Fehlers, wobei ich Kiffis Beispiel
auf das Wesentliche reduziert habe:
Code: Alles auswählen
Procedure test_1() ; OK .....
Debug "Start_1"
If Date() > Val("34") * 1024
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_2(FileName1$, FileName2$) ; OK .....
Debug "Start_2"
If FileSize(FileName1$) > FileSize(FileName2$)
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_3(FileName1$) ; OK .....
Debug "Start_3"
If FileSize(FileName1$) > 34 * 1024
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_4(FileName1$) ; OK .....
Debug "Start_4"
wert = Val("34") * 1024
If FileSize(FileName1$) > wert
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_5(FileName1$) ; OK .....
Debug "Start_5"
If FileSize(FileName1$) > Val("34")
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_6(FileName1$) ; OK .....
Debug "Start_6"
If FileSize(FileName1$) > ValQ("34") * 1024
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
Procedure test_7(FileName1$) ; NOT OK .....
Debug "Start_7"
If FileSize(FileName1$) > Val("34") * 1024
Debug "True"
Else
Debug "False"
EndIf
a$ = "BLABLA"
Debug a$
EndProcedure
FileName1$ = GetTemporaryDirectory() + "Versuch1"
FileName2$ = GetTemporaryDirectory() + "Versuch2"
If CreateFile(100, FileName1$)
WriteString(100, Space(100))
CloseFile(100)
EndIf
If CreateFile(100, FileName2$)
WriteString(100, Space(200))
CloseFile(100)
EndIf
Debug "Procedure test_1"
test_1()
Debug "Procedure test_1 = OK"
Debug "Procedure test_2"
test_2(FileName1$, FileName2$)
Debug "Procedure test_2 = OK"
Debug "Procedure test_3"
test_3(FileName1$)
Debug "Procedure test_3 = OK"
Debug "Procedure test_4"
test_4(FileName1$)
Debug "Procedure test_4 = OK"
Debug "Procedure test_5"
test_5(FileName1$)
Debug "Procedure test_5 = OK"
Debug "Procedure test_6"
test_6(FileName1$)
Debug "Procedure test_6 = OK"
Debug "Procedure test_7"
test_7(FileName1$)
Debug "Procedure test_7 = OK"
Debug "End"
End
Folgendes passiert:
a)
Bei test_1 gar nichts ... Date() liefert offenbar ein für den Vergleich "kompatibles" Ergebnis
b)
Bei test_2 werden zwei Ergebnisse von FileSize() verglichen ... auch ok
c)
test_3 zeigt, dass die Multiplikation beim Vergleich auch nicht stört.
d)
test_4 zeigt, wie von Kiffi erwähnt, dass eine Herausführung auf eine Variable vor dem Vergleich
auch funktioniert.
e)
test_5 zeigt, dass es an VAL() alleine auch nicht liegen kann ....
f)
test_6 läuft einwandfrei, wir konvertieren den String mit ValQ()
und stellen dieselbe Situation her wie in test_2, nämlich den
Vergleich von Quads.
g)
Bei test_7 tritt jetzt der Fehler auf. Es liegt also eindeutig an der
Kombination von FileSize() mit einer Funktionsrückgabe (hier Val() ) in
Verbindung mit der Multiplikation.
Bei der nächsten Variablenzuweisung (hier a$ = "..." ) gibt es dann Crash.
(oder bei ProcedureReturn eben ...). Läßt man die a$ Zuweisung weg,
so hängt sich das Programm bei mir kommentarlos auf.
Offensichtlich passiert beim Vergleich des Quad-Ergebnisses von
FileSize() mit dem Long-Ergebnis der Multiplikation der Speicherfehler.
Bleibt die Frage an die Entwickler, ob Vergleichsoperationen mit
unterschiedlichen Variablentypen uneingeschränkt zulässig sind.
(Wäre schon nicht schlecht ....
)
Der Bug liegt also offensichtlich beim Quad-Long Vergleich unter
"erschwerten" Bedingungen (= Multiplikation von Funktionsergebnissen)
Könnte das jemand ins englische Bugforum stellen? Ich bin dort nicht
sehr präsent ... vielen Dank
Cu Team100
Kompliziert kann es jeder lösen, aber das wirklich Geniale ist einfach.....
