Breakpoints in SysUtils / Vcl.Forms gehen nicht

[hzzm]

Hallo,

ich habe gerade eigentlich ein relativ unvermurkstes Delphi, fast aus der Box.

Ich kann aber keine Breakpoints in den Systemeigenen .pas setzen (z.B. SysUtils oder Vcl.Forms).
Sie werden nach Run einfach gruen, als ob alles wegoptimiert werden wuerde, obwohl Optimierung fuer Debug aus ist.
Oder als ob der Code nie ausgefuehrt werden wuerde. Wird er aber.

So Breake ich jede Zeile in

Delphi-Quellcode:

procedure SysUtils.DoExitProc;

und ich weiss 100%ig, dass der Code ausgefuehrt wird (weil ich dort eine AV kriege),
die werden aber alle Gruen.

Ich hab die Forumsuche und Google benutzt, aber komischerweise bin ich grad zu ungeschickt, da was zu zu finden...

Danke.

Edit: Bei Ctrl+Click auf

Delphi-Quellcode:

uaes SysUtils;

sehe ich auch den SysUtils code. Es scheitert also nicht daran, dass RADStudio die Verlinkung zur .pas nicht haette.

[Sherlock]

Du müßtest Debug-DCUs erstellen.

Sherlock

[Der schöne Günther]

Projektoptionen -> Delphi-Compiler -> Compilieren -> Mit Debug-DCUs - Das musst du einschalten.

[hzzm]

Danke erstmal,

"Mit Debug-DCUs" war fuer diese Debug Konfiguration aber seit je her An!
Das ist also leider nicht die Loesung.

Gibt es noch eine andere Moeglichkeit?

[hzzm]

Also das Problem besteht noch immer: In der Millisekunde, in der ich F9 druecke, wird mein Breakpoint in Vcl.Forms gruen.

Zum durchdrehen, so kann ich nicht arbeiten.
Ich habe kuerzlich wieder EurekaLog und FastMM4 installiert, die sind aber deaktiviert/in der .dpr auskommentiert.

Ich schnalls nicht. Ich habe ein eigenes Unit-Verzeichnis fuer diese Debug-Konfiguration, das aber in allen anderen Belangen problemlos verwendet wird (relativer Pfad).

[Uwe Raabe]

Kannst du das mit einem neuen Projekt reproduzieren?

[hzzm]

Ja. In einem Brandneuen Projekt habe ich das gleiche Problem.

[Uwe Raabe]

Überprüf mal die Bibliothekspfade - insbesondere den Eintrag unter Debug-DCU-Pfad.

Läuft das Delphi zufällig auf einem HP-Rechner?

[hzzm]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408599)

Überprüf mal die Bibliothekspfade - insbesondere den Eintrag unter Debug-DCU-Pfad.

Das wars! Vielen Dank!

$(BDS)\lib\Debug
$(BDSLIB)\$(Platform)\debug

haben gefehlt. Da hat wohl jemand "ungeltige Pfade loeschen" gedrueckt. Ich hoffe, da ist nicht noch mehr kaputt gegangen, was ich gerade nciht auf dem Schirm habe...

[Rolf Frei]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408599)

Überprüf mal die Bibliothekspfade - insbesondere den Eintrag unter Debug-DCU-Pfad.

Läuft das Delphi zufällig auf einem HP-Rechner?

HP Rechner? Kannst du das genauer erläutern? Kannst du mir sagen was das für Probleme macht. Unsere Firma will demnächst neue HP Rechner kaufen.

[Uwe Raabe]

Zitat:

Zitat von Rolf Frei (Beitrag 1408781)

HP Rechner? Kannst du das genauer erläutern? Kannst du mir sagen was das für Probleme macht. Unsere Firma will demnächst neue HP Rechner kaufen.

Auf HP Systemen gibt es oft schon eine vordefinierte Umgebungsvariable Platform, die mit der gleichnamigen, von der IDE dynamisch erzeugten kollidiert. Die IDE sagt sich dann "OK, gibt's schon" und plötzlich passt nichts mehr zusammen.

[KodeZwerg]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408783)

Zitat:

Zitat von Rolf Frei (Beitrag 1408781)

HP Rechner? Kannst du das genauer erläutern? Kannst du mir sagen was das für Probleme macht. Unsere Firma will demnächst neue HP Rechner kaufen.

Auf HP Systemen gibt es oft schon eine vordefinierte Umgebungsvariable Platform, die mit der gleichnamigen, von der IDE dynamisch erzeugten kollidiert. Die IDE sagt sich dann "OK, gibt's schon" und plötzlich passt nichts mehr zusammen.

Hier steht das von Uwe geschilderte Problem

Zitat:

Ungültige PLATFORM-Variable - Erstellen von Projekten auf HP Computern schlägt fehl
Zusammenfassung: HP Computers enthalten den Umgebungsvariablennamen PLATFORM, der vom Buildsystem verwendet wird

Das Build-System verwendet eine Umgebungsvariable namens PLATFORM. Gültige Werte sind "Win32", "Win64" oder "OSX32". Wenn PLATFORM auf einen anderen Wert gesetzt ist, werden alle Builds mit dem Fehler fehlschlagen:

Ungültige PLATFORM-Variable "( Wert )" PLATFORM muss einer der folgenden sein: "Win32", "Win64" oder "OSX32".

Wenn die Umgebungsvariable PLATFORM falsch gesetzt ist, führt dies dazu, dass Syntax-Highlighting in der IDE die legale Syntax als illegal meldet.

Bei HP Computern ist diese Umgebungsvariable häufig festgelegt, aber wir können keine Möglichkeit finden, sie zu verwenden.

In den meisten Situationen entfernen Sie die PLATFORM-Umgebungsvariable von Ihrem System, um dieses Problem zu lösen. Hier sind die Schritte dazu:

Klicken Sie mit der rechten Maustaste auf Arbeitsplatz. Abhängig von Ihrem Betriebssystem kann dies von Ihrem Desktop oder von Windows Explorer sein.
Wählen Sie Eigenschaften.
Abhängig von Ihrem Betriebssystem wählen Sie entweder die Registerkarte Erweitert oder Erweiterte Systemeinstellungen
Klicken Sie auf die Schaltfläche Umgebungsvariablen
Suchen Sie die Platform-Umgebungsvariable und klicken Sie auf die Schaltfläche Löschen.
Wenn Sie feststellen, dass das System die PLATFORM-Umgebungsvariable benötigt, muss sie in der RAD Studio-IDE überschrieben oder explizit in der Befehlszeile an MSBuild übergeben werden. Beispiel:

Delphi-Quellcode:

/p:Platform=Win32

. Um die Einstellung der RAD Studio IDE zu überschreiben, wählen Sie Extras | Optionen, Umgebungsoptionen, Umgebungsvariablen. Klicken Sie dann auf Neu und auf eine Variable namens platform mit dem Wert Win32, Win64 oder OSX32.

[hzzm]

Der Vollstgaendigkeit halber:

Bei mir ist es kein HP-Rechner, sondern ein ASUS.