F8 wandert einfach weiter oO

[Hansa]

Hi,

man sehe sich mal folgendes an. Kanns schlecht erklären. An der Stelle im Screenshot ist was falsch. Nun wollte ich mir das mal näher ansehen und habe einen Haltepunkt gesetzt. Source :

Delphi-Quellcode:

showmessage ('1  *'+BoolToStr (KuDS.IsEmpty,true)+'*');
//    KuDS.Close;            <--- Haltepunkt
//    KuDS.SelectSQL.Text := 'SELECT * ...
//    KuDS.Open;
    if not 1=1 (*KuDS.IsEmpty*) then begin
//      KuDS.First;
//      lblKuNr.Caption := KuDS.FieldByName ('NR').AsString;
showmessage ('2  *'+lblKuNr.Caption+'*');
      btnWeiter.SetFocus;
    end
    else begin
      showmessage ('keine Daten vorhanden !');
      edSuch.SetFocus;
    end;

Jetzt erkläre mir mal einer, wieso Delphi durch sämtliche Zeilen dieses Codefragments einfach weiterwandert, egal ob F7/F8. Es schert sich weder um die Kommentare noch, daß ein if und else Zweig vorhanden ist. Um die Showmessages auch nicht. Zeile für Zeile wird vogegangen. Ohne Rücksicht auf Verluste. :shock:

Wer es nicht glaubt : siehe Anhang in chronologischer Abfolge. 8)

[Amateurprofi]

kann ja nicht funktionieren.

Kommentare werden nicht kompiliert, also wird ein Breakpoint auf einem Kommentar auch nicht zu einem Break führen.

Der Ausdruck Not 1=1 ergibt zwingend False (weil 1=1 immer True ergibt).
Deshalb wird der Programmteil

If Not 1=1 then begin
ShowMessage('Text eins');
end else begin
ShowMessage('Text zwei');
end;

so kompiliert :
MOV EAX, Adresse von 'Text zwei'
CALL ShowMessage

Schau Dir das doch mal in der CPU Ansicht an.
Gruß, Klaus

[Hansa]

War das trotz Screenshots immer noch nicht deutlich genug ? :shock: An dem Codeschnipsel bleibt Delphi in jeder Zeile stehen !

Schreibe mal in Mini-Programm :

Delphi-Quellcode:

begin
//   <---- versuche Delphi dazu zu bringen hier anzuhalten
//   <---- oder hier
//   <---- oder hier
showmessage ('Test');  // <--- und diese ShowMessage nicht anzuzeigen
//   <---- oder hier
//   <---- oder hier
//   <---- oder hier
end.

Und mit dem 1=1 kann ich machen was ich will (1=2 oder einfach weglassen), es wird sowohl der if-Zweig als auch der else-Zweig durchlaufen !! Ja, ich weiß 1=1 ist so eine Sache, aber mir fiel nichts besseres ein. Genau weil 1=1 immer true ergibt dürfte NIEMALS der else-Zweig durchlaufen werden, zumindest nicht if und gleichzeitig else !! Dieses Verhalten ist doch eindeutig zu sehen. 8) Und die Kommentare sprechen eigentlich auch für sich. Die waren vorher nicht da. Geändert hat sich dadurch aber nicht.

[Jasocul]

Hansa, was hast du denn gemacht?
Klaus hat völlig recht. Kommentare werden nicht compiliert. Daher würde ein Breakpoint dort nicht wirken.

Ich kenne nur eine Möglichkeit, das so hinzubiegen, dass es wie bei dir abläuft. Aber dafür solltest du zu erfahren sein. Ich bezweifle, dass du während des Debuggens den Source änderst und dann einfach weiter machst, ohne das Programm zu beenden. Oder arbeitest du mit mehreren am selben Source? Sowas habe ich noch nicht getestet. Stell mal sicher, dass nur du am Source arbeitest und das komplette Projekt vollständig compiliert ist.

Schon mal den selben Source an einem andern PC getestet? Ist vielleicht deine Delphi-Installation im Eimer? Normal ist die Reaktion jedenfalls nicht.

[Union]

Stimmt, Hansa. Deine EXE stimmt einfach nicht mit dem Source überein. Eigentlich führt das Programm gerade das aus, was mal vorher in diesen Source-Zeilen stand.

[jim_raynor]

Vielleicht hast auch einfach irgendwo noch eine zweite dcu Datei, die Delphi verwendet.

[Elvis]

:shock: Da ist jemand seit 3 1/2 Jahren hier angemeldet (verwendet also min. solange delphi) und kennt den Unterschied zwischen Compile/Build nicht?
Faszinierend... :gruebel:

[Jasocul]

@Elvis:
Da ich der einzige bin, der hier auf das Compilieren verwiesen hat, verwechselst du wohl was. Ich bin noch keine 3 1/2 Jahre in der DP. Allerdings kenne ich den Unterschied genau. Genauso, wie Hansa ihn kennt. Deswegen halte ich es ja auch für unwahrscheinlich, dass er diesen Fehler gemacht hat. Vorsichtshalber hatte ich "vollständig compilieren" geschrieben, damit es deutlicher ist.
Übrigens kannst du aus dem Anmeldatum nicht schließen, wie viel Programmier-Erfahrung jemand hat. Es gibt Programmierer, die machen das zum Zeitvertreib und haben auch nach 3 1/2 Jahren immer noch ein Brett vor dem Kopf und es gibt solche, die sich nach 25 Jahren professioneller Programmierung mal in einem Forum anmelden. Also immer ganz ruhig bleiben. :zwinker:

[Hansa]

Zitat:

Zitat von Elvis

:shock: Da ist jemand seit 3 1/2 Jahren hier angemeldet (verwendet also min. solange delphi) und kennt den Unterschied zwischen Compile/Build nicht?
Faszinierend... :gruebel:

Ja, es ist schon faszinierend, welchen Unfug mancher schreibt. :lol: Solche Schlußfolgerungen führen wohl auch zu diesen dämlichen Verschwörungstheorien. Wie wäre es mit "Elvis lebt" ? :lol: Und wenn tatsächlich einer nicht weiß was Build ist oder was eine DCU ist, dann schreibe das nächste mal hin, was das eben ist. Was bei F9 passiert, das weißt du aber, Ja ? Was wohl ? Alle im Source veränderten Units werden neu compiliert. Das dies in diesem Fall oft gemacht wurde (siehe Kommentare, die nacheinander eingefügt wurden), das sieht sogar ein Blinder mit Krückstock. Natürlich habe ich des öfteren ein Build gemacht, denn es könnte ja sein, daß eine Unit den Effekt hervorruft, bei der ich mit einem geänderten Systemdatum was geändert habe. Das seltsame ist eben, daß obwohl die Kommentare nicht compiliert werden F8 dort anhält.

[Hansa]

doppelt

[Union]

Hansa,

ist denn Dein Problem jetzt gelöst oder nicht?

[shmia]

Wenn die Breakpoints nicht mit dem Sourcecode übereinstimmen, liegt das sehr häufig daran,
dass der Sourcecode nur CR oder nur LF anstelle von CR+LF enthält.
http://www.delphipraxis.net/internal...ct.php?t=62243

[sh17]

Das Problem hatte ich auch manchmal.

Prüfe mal folgendes nach, bzw führe durch:

- Hast Du das Projekt kopiert und das neue Projekt nutzt immer noch die alten Quellen (wg. Suchpfad).

- Lösche mal alle dcu's

- stimmen die Suchpfade? stehen gleichnamige dcu's evtl woanders noch rum

[noidic]

Was auch sein kann ist, dass eine Unit mit dem selben Namen im Suchpfad liegt. Diese wird dann ins Projekt kompiliert, der Debugger läuft aber über die andere. Vielleicht mal dahingehend schaun.

[Amateurprofi]

Zitat:

Genau weil 1=1 immer true ergibt dürfte NIEMALS der else-Zweig durchlaufen werden, zumindest nicht if und gleichzeitig else !!

Hansa,
Du hast völlig Recht, wenn Du sagst, daß 1=1 immer True ergibt.
In Deinem ursprünglichen Beitrag steht aber nicht
If 1=1 then ....
sondern
If Not 1=1 then ...

Und deshalb muss immer nur der Else-Zweig durchlaufen werden.
Wie ich schon schrieb, löst Delphi den ganzen Code
If Not 1=1 then begin
ShowMessage('Text 1');
end else begin
Showmessage('Text 2');
end;

auf und es verbleibt nur noch
ShowMessage('Text 2');

Kein if, kein then, kein else, einfach nur der Befehl ShowMessage.
Ich kanns nur wiederholen : Schau es Dir mal in der CPU-Ansicht an.
Gruß, Klaus

[Christian Seehase]

Moin Hansa,

Zitat:

Zitat von Hansa

Was bei F9 passiert, das weißt du aber, Ja ? Was wohl ? Alle im Source veränderten Units werden neu compiliert.

Theoretisch richtig, aber die Erfahrung lehrt, dass die IDE nicht immer erkennt, ob sich eine Unit geändert hat, und, unter Umständen, eine Unit, die Du geändert hast eben nicht neu compiliert.
Mach doch also einfach mal ein Build, statt nur F9 zu drücken.

[Hansa]

Zitat:

Zitat von Amateurprofi

In Deinem ursprünglichen Beitrag steht aber nicht
If 1=1 then ....
sondern
If Not 1=1 then ...
...
auf und es verbleibt nur noch
ShowMessage('Text 2');

Kein if, kein then, kein else, einfach nur der Befehl ShowMessage.

Der Haken ist nur : if, else und showmessages werden ALLE GLEICHZEITIG nacheinander durchlaufen, egal ob NOT oder eben nicht. Die Kommentare auch. 8) F7 macht übrigens dasselbe. Bevor die DB-Sachen auskommentiert wurden, landete man manchmal in einer DB-Unit, jetzt aber nicht mal in den VCL-Sourcen !

@Chris : das Build ist längst mehrmals gemacht worden und wegen keiner Änderung wurden auch die DCUs gelöscht. Mit F8 muß die EXE ja wohl durch die verlinkte DCU wandern und nicht irgendwo im Wald rum. Also dürfte Delphi wissen, wo der Source der DCU zu finden ist und benutzt nicht irgendeinen anderen. Daraus folgere ich : BUG ! So was behaupte ich ungern, aber in dem Fall bleibt wohl nichts anderes übrig, denn es läßt sich tatsächlich reproduzieren. Allerdings eher ein Win-Bug. Denn nach dem Neustart des Rechners war der Effekt nicht mehr zu bemerken. Kompletter Source ist aber gesichert und ich kann den Zustand jederzeit wiederherstellen.

[Amateurprofi]

Zitat:

Der Haken ist nur : if, else und showmessages werden ALLE GLEICHZEITIG nacheinander durchlaufen, egal ob NOT oder eben nicht. Die Kommentare auch. 8) F7 macht übrigens dasselbe. Bevor die DB-Sachen auskommentiert wurden, landete man manchmal in einer DB-Unit, jetzt aber nicht mal in den VCL-Sourcen

!

Hansa,
Nein, es ist nicht egal ob du "if 1=1" oder "if Not 1=1" schreibst.

Wenn Du If Not 1=1 schreibst dann wird der ganze Code umgewandelt in
ShowMessage('Text2') also der Else Zweig
Dagegen, wenn Du If 1=1 schreibst dann wird der ganze Code umgewandelt in
ShowMessage('Text1') also der If Zweig

In jedem Fall besteht das Kompilat ausschließlich aus dem Befehl ShowMessage(..), entweder mit dem Text aus dem If-Zweig oder dem aus dem Else-Zweig.

Und da das nur ein einziger Befehl ist wird er auch mit F7 genau so ausgeführt wie mit F8.
Gruß, Klaus

[Hansa]

Zitat:

Zitat von Amateurprofi

In jedem Fall besteht das Kompilat ausschließlich aus dem Befehl ShowMessage(..), entweder mit dem Text aus dem If-Zweig oder dem aus dem Else-Zweig.

Wie oft denn noch ? Siehe die Screenshots. IF, ELSE und auch ShowMessage wird durchlaufen. egal was ist. 8) Wozu ist denn IF und ELSE da, wenn es gar nicht interessiert ? Wer hier was schreibt, der weiß doch wohl immerhin, was IF ELSE oder ein Kommentar bedeutet ? :shock: Oder etwa nicht ? :mrgreen:

[Matze]

Tritt das jedesmal auf oder war das nur einmal so? Hast du mal versucht, die dcus zu löschen und dann zu kompilieren? Dann könnte man schonmal sicher gehen, dass der Compiler die aktuellen Unis auch verwendet.

[Jasocul]

@matze:

Zitat:

Zitat von Hansa

Und mit dem 1=1 kann ich machen was ich will (1=2 oder einfach weglassen), es wird sowohl der if-Zweig als auch der else-Zweig durchlaufen !! Ja, ich weiß 1=1 ist so eine Sache, aber mir fiel nichts besseres ein. Genau weil 1=1 immer true ergibt dürfte NIEMALS der else-Zweig durchlaufen werden, zumindest nicht if und gleichzeitig else !! Dieses Verhalten ist doch eindeutig zu sehen. 8) Und die Kommentare sprechen eigentlich auch für sich. Die waren vorher nicht da. Geändert hat sich dadurch aber nicht.

Auch wenn du prinzipiell Recht hast, so dürfte aber auch NUR der else-Fall durchlaufen werden. Bei Hansa wird beides durchlaufen. Ich wollte Hansa das selbe schreiben, bis ich mir das nochmal genau durchgelesen hatte.

[mschaefer]

Moin zusammen


Das leidige Thema Breakpoints

Grüße // Martin


[Edit] Link auf Hinweis von Dfried korrigiert: Sorry [/ Edit]

[dfried]

Zitat:

Zitat von mschaefer

Das leidige Thema Breakpoints

Muss ja ein ziemlich leidiges Thema sein, dein Link auf die Suche bringt nicht ein Ergebnis :mrgreen: