Haltepunkte werden nicht erreicht

[Angel4585]

Hallo,

in einem Projekt habe ich gerade das Problem, dass ich Haltepunkte drin habe, die angeblich jedoch nicht erreicht werden, also so durchkreuzt sind.
Um zu testen ob es an der Codestelle liegt habe ich direkt auf das Application.Initialize einen Haltepunkt gesetzt.
Selbst dort tritt das auf.
Das Projekt wird beim drücken von F9 aber ganz normal ausgeführt, wie mit nem Debugger.
Nur dass er nicht bei den Haltepunkten anhält.

Ich hab jetzt schon einen andern Thread hier entdeckt, der sich mit dem Thema Haltepunkte beschäftigt: http://www.delphipraxis.net/44170-le...ml#post1050779
Hat mir leider nicht weitergeholfen.

Checkliste:
[x]Projektoptionen->Delphi-Compiler->Compilieren->Debug-Informationen
[x]Tools->Optionen->Debugger-Optionen->Integriertes Debuggen

Das sind denke ich die zwei wichtigsten, sonst weis ich nicht was ich noch einstellen kann.
An was kann das noch liegen?

Edit: In anderen Projekten funktioniert das debuggen problemlos

[Bernhard Geyer]

Hast du das Projekt komplett neu übersetzt (Erzeugen). Ein einfaches Kompilieren sorgt nicht dafür das die nötigen DCU-Dateien mit Debug-Infos neu erzeugt werden.

[DeddyH]

Steht die Build-Konfiguration auf Debug oder Release?

[Angel4585]

Ah da hammas.
Die Build-Konfiguration stand auf Debug, aber Compilieren allein hat nicht gereicht.
Ich bin auf Erzeugen gegangen, dann hats alle dcu's mal erzeugt un dann gingen auch die Haltepunkte :thumb:

[Sir Rufo]

Um dieses Problem zu umgehen kann man in den Projekt-Optionen folgendes einstellen:

Code:

Ausgabeverzeichnis für Units = .\dcu\$(Config)

und alles wird gut

[mleyen]

Zitat:

Zitat von Sir Rufo (Beitrag 1083418)

und alles wird gut

Oder man geht Notfalls hin und löscht alle Dateien bis auf *.dpr, *.pas und *.dfm und lädt dann die gespeicherten Builds. :wink:

[Sir Rufo]

Zitat:

Zitat von mleyen (Beitrag 1083421)

Zitat:

Zitat von Sir Rufo (Beitrag 1083418)

und alles wird gut

Oder man geht Notfalls hin und löscht alle Dateien bis auf *.dpr, *.pas und *.dfm und lädt dann die gespeicherten Builds. :wink:

In *.dproj stehen die ganzen Projekteinstellungen drin (Version, Ausgabeverzeichnis, etc.) warum sollte man die löschen?
*.inc könnte auch was wichtiges drinstehen

Und da gibt es noch einen Haufen Dateien, die ebenfalls wichtig sein könnten ...

Als PreBuild-Ereignis könnte man die *.dcu und *.exe löschen, ok aber mit dem unterschiedlichen Ausgabeverzeichnissen für die DCUs ist das wesentlich einfacher im Handling

[mleyen]

Zitat:

Zitat von Sir Rufo (Beitrag 1083422)

In *.dproj stehen die ganzen Projekteinstellungen drin (Version, Ausgabeverzeichnis, etc.) warum sollte man die löschen?

Damit man schnellstmöglich etwas zum Debuggen/Laufen bekommt und sich nicht lange um Netzwerk-, Einstellungsprobleme, zerschossenen Dateien usw kümmern muss.
Kommt halt auf Projekt(größe)/Zeit an.

[Luckie]

Zitat:

Zitat von Angel4585 (Beitrag 1083402)

Checkliste:
[x]Projektoptionen->Delphi-Compiler->Compilieren->Debug-Informationen
[x]Tools->Optionen->Debugger-Optionen->Integriertes Debuggen

Das habe ich auch schon alles gemacht und auch das Projekt neu erzeugt, auch vorher die dcus gelöscht. Aber das BDS2006 hält bei einem NonVCL Projekt einfach nicht an den Haltepunkten an. Was kann ich noch machen? Ach ja, wo kann man denn die Builkd-Konfiguration umstellen oder gibt es das beim BDS2006 noch nicht?

Bei einem neuen VCL-Projekt funktionieren die Haltepunkte übrigens.

[himitsu]

Eigentlich sollte es keinen Unterschied machen, ob VCL oder NonVCL.

Die SysUtils hast du aber nicht eingebunden?
Dort drin wird wird ja eine Fehlerbehandlung initialisiert.



Die Haltepunkte sind auch aktiv (rot) und man sieht ansonsten die blauen Codepunkte?

Was passiert, wenn du dein Progamm mit F7 startest?

Im Notfall könntest du noch

Delphi-Quellcode:

asm int 3 end;

oder DebugBreak verwenden.

[Luckie]

Nein, die SysUtils wird nicht verwendet. Die braucht man ja nur für die Exceptions. Und mit F7 laden ich sofort im CPU Fenster, was auch nicht gerade optimal ist.

[jaenicke]

Du könntest einmal die .bdsproj Datei umbenennen (und die .local, ... löschen) und dann die .dpr öffnen. Dann erzeugt Delphi eine neue Standardprojektdatei. Wenn es an Einstellungen daraus lag, sollte es dann behoben sein.

Wenn es dann immer noch nicht geht, wird wohl auf die falschen Dateien zugegriffen. Aber dazu schreibe ich erst mehr, wenn das andere nicht funktioniert hat. ;-)

[Luckie]

Na, dann schreib mal mehr. :(

[jaenicke]

Erstens:
Was passiert, wenn du ein neues Projekt erstellst, die neue Unit dort herauswirfst und die alten aus deinem aktuellen Projekt dort hineinpackst? Funktioniert es dann?

Wenn nicht, schau am besten einmal mit dem Process Monitor welche .dcu Dateien und welche Pfade eigentlich beim Kompilieren und Debuggen benutzt werden.

[Luckie]

Die Haltepunkte stehen in der dpr-Datei, da kann ich nichts austauschen. Und die aktuellen dcus werden verwendet, da die Änderungen im Code der dpr wirksam werden.

[bernerbaer]

Anderer Ansatz:
Da war doch irgendwann mal was mit den Logitechtreibern, ich kann mich erinnern vor Jahren mal das selbe Problem gehabt zu haben. Mit dem Borland oder Codegear Support (ich weiss nicht mehr wer damals zuständig war), habe ich dann eine Logitech Webcam als Verursacher herausgefunden. Nach der Deinstallation der Logitechtreiber funktionierten meine Breakpoints wieder wie gewohnt.

[Luckie]

In einem neuen VCL Projekt funktionieren sie ja wie sie sollen. Das kann es also auch nicht sein.

[himitsu]

Eine neue normale Konsolenanwendung kannst'e auch debuggen?

[freeway]

ist mir Heute unter XE2 auch passiert das der Haltepunkt ignoriert wurde
Die DCU´s löschen hat nicht geholfen (Integriertes Debuggen aktiv)
geholfen hat: von einer älteren Sicherungskopie dpr / dproj / dproj.local in das Projekt Verzeichniss kopieren
Scheint mit dem Punkt "Zum Neuerzeugen beim Debuggen geänderte Projekte auffordern" zusammenzuhängen...

[Assarbad]

Workaround: man rufe selber DebugBreak auf. Wird dieser Breakpoint nicht erreicht, wird der entsprechende Code nicht ausgeführt. Bei anderen Dingen kann auch immer der Optimierer dazwischengrätschen.