BDS 2006 ändert Breakpoint

Gerhard_S · Beiträge: 98

Mein BDS 2006 ändert gesetzte Breakpoints: zur Laufzeit ist die markierte Zeile grün unterlegt, der rote Kreis mit einem x versehen.
Allerdings geschieht das nur in einem Projekt; in anderen funktioniert alles wie üblich.
Ich habe schon die DCUs gelöscht und neu erstellen lassen - ohne Erfolg. Auch die Bearbeitung des Quelltexts mit einem anderen Editor hilft nicht.
Kennt jemand das Problem?

Xentar · Verfasst: Di 16.12.08 13:11

Das bedeutet, dass der Haltepunkt auf einer "ungültigen" Zeile gesetzt wurde, also einer Zeile, die niemals durchlaufen wird (z.B. Leerzeilen).
Kompilier das Projekt mal mit STRG + F9, dann müssten links vom Quellcode so kleine blaue Punkte auftauchen - tun sie das, in dieser betreffenden Unit?
Wenn nicht: Handelt es sich bei der Unit um einen Teil des Projektes, oder eine "Fremdkomponenten"?

_________________
PROGRAMMER: A device for converting coffee into software.

jaenicke · Verfasst: Di 16.12.08 13:24

Dies kann wenn ich mich recht entsinne z.B. bei Casts u.ä. passieren, wenn der Compiler nicht erkennen kann, dass der Code tatsächlich aufgerufen wird. In diesem Fall markiert Delphi diese Zeilen entsprechend, weil es so aussieht, dass diese nie aufgerufen werden.
Auch beim Debuggen von DLLs kann das vorkommen.

Sollte ein solcher Code dann doch erreicht werden und der Haltepunkt erreicht, dann funktioniert dennoch alles normal.

Gerhard_S · Beiträge: 98

Ich habe das Projekt mit Strg-F9 neu kompiliert: die blauen Pünktchen erscheinen. Wenn ich es danach starte, kommt das alte Bild: die Breakpoint-Zeile ist grün unterlegt, der Breakpoint durchgekreuzt.
Die Unit ist selbstgeschrieben, der Code an der betreffenden Stelle wird auf jeden Fall durchlaufen (geprüft mit "visual debugging" aka ShowMessage).

jaenicke · Verfasst: Di 16.12.08 14:41

Und du hast auch keine Zeile erwischt, die keinen Code enthält, z.B. bei einem mehrzeiligen Befehl? Also der Breakpoint sitzt auf einem der blauen Punkte?

Wie sieht der Code denn an der Stelle aus?

Gerhard_S · Beiträge: 98

Ich habe ein bisschen experimentiert und den Code in ein neues Projekt ausgelagert, wo das Tracing mit Breakpoints wieder funktioniert:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

procedure TForm1.Button2Click(Sender: TObject);
var BigStr, clstr: string;  o, p, k, n: integer;
begin
BigStr:= Memo1.Text;
clstr := 'class=';
p := 1;
k := PosEx(clstr, BigStr, p);
n := Length(clstr);
for clstr in BigStr do
      begin
      Insert('"', BigStr, k+n); //<-- hier Breakpoint gesetzt
      o := PosEx('>', BigStr, k+n); 
      Insert('"', BigStr, o);
      Inc(k);
      end;
Memo1.Text := BigStr;
Memo1.Update;
Memo1.SelStart:= 0;
end;

Offensichtlich hat die Unit, in der das Tracing mit Breakpoints nicht funktioniert, einen verborgenen Defekt.
(Die Prozedur macht etwas anderes als vom Autor gewollt, aber das ist schon ein anderes Thema.)

Moderiert von AXMD: Quote- durch Delphi-Tags ersetzt

Xentar · Verfasst: Di 16.12.08 15:13

Schau dir die Datei mal im normalen Editor an:
Kann es sein, dass hier die Zeilenumbrüche vermurkst sind?

_________________
PROGRAMMER: A device for converting coffee into software.

Chemiker · Verfasst: Di 16.12.08 21:10

Hallo Gerhard_S,

das Verhalten zeigt der Compiler auch, wenn der Ausdruck den man mit einem Haltpunkt markiert, keinen Sinn ergibt.

z.B.

markieren

Delphi-Quelltext

1:
2:
3:
4:

var
  s: Integer;
begin
   s:=s+1;

wenn man nun die Zeile s:=s+1 mit einem Haltpunkt versieht und anschließend s nicht weiterverwendet, so wird der Haltepunkt übergangen und mit einem Kreuz versehen.

Bis bald Chemiker

Xentar · Verfasst: Di 16.12.08 21:12

Ja, weil der Compiler den Code optimiert, und dabei feststellt, dass diese Zeile unnötig ist, weil danach nicht mehr verwendet (gibt auch einen entsprechenden Hinweis).
Somit wird die Zeile auch niemals durchlaufen.

_________________
PROGRAMMER: A device for converting coffee into software.

jaenicke · Verfasst: Di 16.12.08 21:23

Xentar hat folgendes geschrieben :

Ja, weil der Compiler den Code optimiert, und dabei feststellt, dass diese Zeile unnötig ist, weil danach nicht mehr verwendet (gibt auch einen entsprechenden Hinweis).

Ich bin mal davon ausgegangen, dass das nicht der Fall ist, Warnungen und Hinweise setze ich natürlich als nicht vorhanden voraus bei einer solchen Frage. ;-)

Xentar · Verfasst: Di 16.12.08 22:37

jaenicke hat folgendes geschrieben :

Xentar hat folgendes geschrieben :

Ja, weil der Compiler den Code optimiert, und dabei feststellt, dass diese Zeile unnötig ist, weil danach nicht mehr verwendet (gibt auch einen entsprechenden Hinweis).

Ich bin mal davon ausgegangen, dass das nicht der Fall ist, Warnungen und Hinweise setze ich natürlich als nicht vorhanden voraus bei einer solchen Frage. ;-)

Ich hätte zitieren sollen

Meinte eigentlich das Beispiel von user profile icon

Chemiker - da sollte ein Hinweis ausgegeben werden, wenn s nicht weiter verwendet wird.

_________________
PROGRAMMER: A device for converting coffee into software.

jaenicke · Verfasst: Di 16.12.08 22:49

Das meinte ich auch, dass ich seine Erklärung als Ursache für das Problem deshalb gar nicht in Betracht gezogen hatte. ;-)

Gerhard_S · Beiträge: 98

Das Problem ist inzwischen gelöst - durch Löschen der cfg-Datei und der zwei bdsproj-Dateien (exename.bdsproj und exename.bdsproj.local) und nachfolgendem Neuaufbau dieser Dateien durch Aufruf von exename.dpr.
Bei mir war es hervorgerufen durch Ausschließen und späteres Reintegrieren einer Unit.

Chemiker · Verfasst: Fr 19.12.08 01:03

Hallo jaenike u. Xentar,

Gerhard_S hat folgendes geschrieben:

Die Unit ist selbstgeschrieben, der Code an der betreffenden Stelle wird auf jeden Fall durchlaufen (geprüft mit "visual debugging" aka ShowMessage).

meine Vermutung, lag an diesem Zitat. Wenn die Variable damit ausgegeben wird, ist für den Compiler der Code nicht mehr sinnlos.

Bis bald Chemiker

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme