Seltsames Runtime-Verhalten (50 ist kleiner 1?)

[Codehunter]

Moin!

Ich habe hier ein ganz seltsames Runtime-Verhalten. Bild 1 zeigt die Zeile 294, wo ich den Cursor grad auf der Variable "I" stehen hab und wie man im Hint sieht, enthält sie den Wert 50. Wenn ich jetzt F8 drücke wäre also der Vergleich in Zeile 294 "if 50 >= 0 then...". Meiner bescheidenen Erfahrung nach müsste doch jetzt Zeile 295 angesprungen werden. Tuts aber nicht, ich lande in Zeile 297, also am Ende der Function. Auch dann ist I immer noch 50, wird also nicht zufällig irgendwo im Speicher überschrieben.

Hat jemand eine Idee? Hab schon alle DCUs gelöscht und alles neu erzeugt. Ohne Besserung. Ich werde noch wahnsinnig mit diesem Bug...

Grüße
Cody

PS: Delphi 10 mit Target Android.

[Lemmy]

Hi,

I doppelt deklariert?
ist die Methode in einem Formular, das ggf. doppelt erzeugt wurde (einmal automatisch, einmal von Hand)?

Grüße

[baumina]

Um solchen seltsamen Dingen auf die Spur zu kommen, gehe ich meist so vor:

- mal F7 statt F8 ausprobieren
- showmessages einbauen
- else-Zweig einfügen

[Neutral General]

Erstell das Projekt mal neu, DCUs löschen, sichergehen dass es nicht 2 verschiedene Versionen dieser Datei gibt und aus welchen Gründen auch immer die falsche genommen wird.
Mach wie schon gesagt mal ne Messagebox rein, wenn diese (weder innerhalb noch außerhalb des ifs angezeigt wird dann nimmt er ziemlich sicher die falsche Datei.

[Mavarik]

DCU <> Pas File

[Uwe Raabe]

Zitat von Codehunter:

PS: Delphi 10 mit Target Android.

Beim Remote-Debugging auf Android habe ich tatsächlich auch schon festgestellt, daß die angezeigten Variableninhalte nicht immer passen.

[Neutral General]

Zitat von Mavarik:

DCU <> Pas File

Was willst du mir damit sagen? Das ist mir auch klar
Aber meiner Erfahrung nach kann es sowohl an der DCU als auch an der (doppelt vorhandenen) PAS liegen

[Codehunter]

Zitat von Uwe Raabe:

Beim Remote-Debugging auf Android habe ich tatsächlich auch schon festgestellt, daß die angezeigten Variableninhalte nicht immer passen.

Genau sowas muss es sein. Ich habe das jetzt auf anderen Wegen geloggt und dabei gleich zwei voneinander unabhängige Bugs gefunden, die zusammen mit dem falsch angezeigten Variableninhalt mich stundenlang in die Irre geführt haben. Mich würde aber mal interessieren, warum der Debugger falsche Werte anzeigt. Wenns wenigstens zufällige Werte wären könnte ich es ja noch mit Pointergeschubse erklären. Aber es sind reproduzierbar immer die gleichen falschen Werte. An faulen DCUs liegts jedenfalls nicht, die habe ich immer sauber weggeputzt vor dem Kompilieren.

@Uwe: Ist das Einzelschritt-Debugging bei dir auch so gähnend langsam? Bei mir so ca. 3 Sekunden pro Step. Oder liegt es daran dass ich D10 in einer VM laufen habe?

[Uwe Raabe]

Zitat von Codehunter:

@Uwe: Ist das Einzelschritt-Debugging bei dir auch so gähnend langsam? Bei mir so ca. 3 Sekunden pro Step. Oder liegt es daran dass ich D10 in einer VM laufen habe?

Beim Remote-Debugging kann das schon mal etwas länger dauern. Ich vermeide das weitestgehend und debugge das meiste unter Win32. Nur wo das nicht mehr geht weiche ich dann auf Remote-Debugging aus.

Du lässt es aber schon auf einem echten Gerät laufen und nicht unter dem Android-Simulator, oder?

[Codehunter]

Zitat von Uwe Raabe:

Du lässt es aber schon auf einem echten Gerät laufen und nicht unter dem Android-Simulator, oder?

Honeywell Dolphin 75e. Das Problem ist dass ich auf den 2D-Imager in den Kisten angewiesen bin, weshalb Testen auf Win32 nur seeeeeehr begrenzt möglich ist. Für das reine Imager-I/O habe ich mir zwar eine Art Emulator für Windows gebastelt. Allerdings habe ich dort das Problem, dass sich Android-System-Intents nicht simulieren lassen und sich die asynchrone Runtime oftmals ganz anders verhält, insbesondere was Timings und Timeouts angeht.