Breakpoint setzen versagt in Unit...; Delphi 6

[maanton]

Hallo,

ich hab schon was ähnliches über die Suche gesehen, aber das Thema wurde nicht erfolgreich behandelt.

Ich möchte einen Breakpoint setzen, aber er mag mich nicht.

Breakpoint(s) sollen in einer Unit (einem Thread) gesetzt werden, in der ganzen Unit gehen die Dinger nicht.
In anderen Units gehn die Breaks. Auch in einem von der Unit aufgerufenen Fenster( besser : dessen Routinen) funzt es.

Es ist auch die richtige Unit (statisch im Hauptprogramm) - die Unit hab ich gestern komplett umgestellt - gibt es sonst nicht auf dem Rechner. (Das Thema mit nicht funktionierenden Breaks hat ich schon mit eingebundenen DLLs).
Der Thread ruft ein Fenster auf - das Fenster kommt und funktioniert (nicht so 100% - aber das schieb ich auf Fehler in der "neuen" Füllroutine...). Thread schreibt auch korrekt seine Ausführung in LogDatei.


Ein bisserl Code :

Delphi-Quellcode:

ThreadNeueAdresse.Execute;
var Messg : TMsg;
    nilpointer : pointer;
    ErrorInfo : TErrorInfo;
    bFertigMitFenster : boolean;
    nWindowsCount : integer;

begin
  bFertigMitFenster := false; <- breakpoint hier geht nicht
  if MainHWND = 0 then begin
    ...
    exit
  end;
  PeekMessage(...); <- break auch hier  geht nicht
 ...

end;

Was mach ich falsch, was hab ich übersehen ? Möglicherweise eine Einstellung spezifisch für die Unit in der IDE ?
Gemacht hab ich:
IDE-Neustart, Rechner Neustart,
{$D-} im Projekt schon gesucht - auch "händisch".
DCU-Datei schon gelöscht.
Compiler macht auch keine Optimierung mehr.
Was hab ich noch nicht gemacht : Code von gestern (vor den Änderungen) eingespielt .

Gruss
maanton

[SirThornberry]

wie heißt die unit?
hast du sie dem Projekt hinzugefügt?
Hast du auch keine Unit die den gleichen Namen hat so das eventuell die andere genommen wurde?

[alzaimar]

Dieses Verhalten hat mich auch an den Rand der Verzweifung gebracht. Ursache ist immer(!)

a) DCU gleichen Namens in einem anderen* Verzeichnis
b) PAS gleichen Namens in einem anderen* Verzeichnis

* Dieses andere Verzeichnis wird von Delphi beim Kompilieren früher gescannt, als die von dir sichtbare Datei.

Stelle einfach sicher (wie der Sir schon gesagt hat), das es keine DCU bzw. PAS Datei auf der Platte gibt.

Ich verwende einige blöde Tricks, wenn ich mir nicht ganz sicher bin:
1. Nach dem Kompilieren werden im IDE-Editor alle Zeilen mit so einem blauen Bupsel markiert. Wenn diese beim Starten des Programms NICHT verschwinden, scheidet a) aus.
2. Irgendwo in der Unit einen Syntaxfehler produzieren und Kompilieren. Wird der Fehler erkannt, scheidet b) aus.

Sollte damit eigentlich funktionieren.

Sehr lustig sind auc Effekte, wo die Zeileninformation nicht mehr stimmt, dann werden 'Var'-Zeilen plötzlich zu Programmzeilen und Programmfehler werden z.B. hier angezeigt:

Delphi-Quellcode:

End;
// hier tritt der Fehler auf, hö hö

Procedure FooBar;

[Delphi-Laie]

Zitat von alzaimar:

Dieses Verhalten hat mich auch an den Rand der Verzweifung gebracht. Ursache ist immer(!)

a) DCU gleichen Namens in einem anderen* Verzeichnis
b) PAS gleichen Namens in einem anderen* Verzeichnis

* Dieses andere Verzeichnis wird von Delphi beim Kompilieren früher gescannt, als die von dir sichtbare Datei.

Stelle einfach sicher (wie der Sir schon gesagt hat), das es keine DCU bzw. PAS Datei auf der Platte gibt.

Nein, alzaimar, das ist leider nicht immer die Ursache.

Zur Zeit quäle ich mich mit den Units der Langzahlenbibliothek "NX" von Marcel Martin. Weder Delphi4 noch Delphi 5 ist in der Lage, irgendwelche potentiellen Breakpoints in den betreffenden Units anzuzeigen, geschweige denn, welche zu setzen oder gar bei diesen zu stoppen. Dabei wird Code dort eindeutig ausgeführt (kann man z.B. mit kleinen Pieptönen überprüfen, Initialisationscode wird ohnehin immer ausgeführt), auch dort finden sich keine). Bei anderen eingebundenen "externen" Units im gleichen Projekt finden sich die blauen Punkte hingegen. Namensdoubletten waren tatsächlich vorhanden, doch die sind längst gelöscht, Delphi längst neu gestartet...

Mit Delphi erlebt man zwar im Verlaufe der Jahre auch so manches Abenteuer, aber einen solch brachialen Fehler dieser Programmierumgebung habe ich bisher noch nie erlebt.

[jaenicke]

Hast du die ganzen Dateien wie .identcache und so schon gelöscht? Die verursachen das ganz gerne... also im Grunde alles bis auf (bei Delphi 5) .dpr, .res, .pas und .dfm bei normalen Projekten mit nur Projekt + Formulare.

[Delphi-Laie]

Zitat von jaenicke:

Hast du die ganzen Dateien wie .identcache und so schon gelöscht? Die verursachen das ganz gerne... also im Grunde alles bis auf (bei Delphi 5) .dpr, .res, .pas und .dfm bei normalen Projekten mit nur Projekt + Formulare.

Hallo jaenicke, danke für Deine Reaktion!

Nein, mit .identcache hat das überhaupt nichts zu tun, das Problem steckt tiefer.

Als Anhang sende ich das "heruntergebrochene" Projekt mit, nur, um diesen Fehler zu demonstrieren.

In der Unitdatei zum Formular 1 wird die unit "nx_z.pas" eingebunden. Letztere bekommt beim Compilieren nicht einen (potentiellen) Breakpoint verpaßt. In der Zeile 7994 - gleich unter der "initialization" - habe ich ein beispielhaftes "beep" gesetzt. Beim Starten des Projektes wird das auch - hörbar - ausgeführt. Setzt man dort jedoch einen Breakpoint, wird dieser "wegoptimiert", d.h., er wird grün und führt nicht zum Halten. Und das bei nachweilich ausgeführtem Code.

Dieses Phänomen kann ich von Delphi 4-7 reproduzieren, andere (=höhere) Delphis habe jetzt nicht auf die Schnelle zur Hand.

[jaenicke]

Dort ist das klar, denn bei einem Blick in die nx_symbols.inc blieb mein Blick sofort an dieser Zeile hängen...

Delphi-Quellcode:

{.$DEFINE NX_DEBUG}

// (für den Forenhighlighter, damit der es schafft den Code in eine eigene Zeile zu setzen...)

Und wie vermutet entfernt das in der Einstellung wie bei dir (nicht auf Debug gesetzt) die Debugsymbole:

Delphi-Quellcode:

{$D-}

//

[Dezipaitor]

Hast du schonmal Umschalt+F9 verwendet? = Alles neu kompilieren.

Es kann auch sein, dass es ein Package (bpl) gibt, worin diese Unit enthalten ist. Dann geht die Arbeit aber auch schon richtig lost. Schau mal in den Projektoptionen, ob dort ungewöhnliche Pakete drin sind.

[semo]

projektoption "debug dcu" eingeschaltet?

[maanton]

Hallo !
- also : Die Unit heisst ThreadNeueAdresse.pas
- Die Unit - auch die Source - gibt es nur einmal auf dem Rechner (spez. Entwicklungsrechner nur für dieses Projekt, keine Backups)
- Das Löschen der DCU-DAtei führte zu einer Neuerstellung der DCU (Datum,Uhrzeit passt) - ist also wohl die Richtige
- Bei der Neueingabe von Routinen hattte ich -erwartete- FEhlermeldungen beim Kompilieren
- Das Debuggen in der Unit hat schon mal funktioniert; ist aber schon länger her und ich meine was danach in den Projekteinstellungen geändert zu haben - aber was ?
- debug dcu ist eingeschaltet - wie schon gesagt, die anderen Units gehn...


Meine aktuelle Vermutung ist, dass die Unit im Projekt nicht richtig (oder mehrfach) angemeldet ist. Werde daher das Projekt neu aufsetzen. Könnte sein, dass ich als Neueinsteiger damals (bei Projektübernahme) dort falsche Einstellungen vorgenommen habe.

Melde mich, wenn damit durch ... .

Gruss
und ein schoenes Rest WE
maanton