Breakpoints in D7 nicht erreichbar

[Nic2012]

Hallo,
ich habe hier ein altes D7-Projekt "geerbt". Dieses hat u.a. ein sehr umfangreiches Daten-Modul mit etwa 400 deklarierten Methoden, ca. 200 Objekten (TSmartQuery, TOraStoredProc) und insgesamt 10000 Zeilen Code.

Nach dem Erzeugen des Projekts sind nur in den letzten 1800 Zeilen die blauen Marker (für mögliche Breakpoints). Setze ich Breakpoints an anderer Stelle im Code, ist ein Debuggen nicht möglich bzw. stopt der Debugger NICHT an gewünschter Stelle. Das ist für der Fehlersuche und im Hinblick auf die Größe des DM-Moduls mehr als hinderlich.

Die DFM hat ca. 534 kB, die Unit ca. 366 kB.
Bevor ich mich vorsichtig an Refactoring mache wollte ich wissen ob für D7 Limits bzgl. maximaler Dateigrößen der DFM, Unit und max. Zeilenanzahl gibt, um noch vernünftig zu debuggen ?

Gruß, Nic

PS: Sachdienliche Hinweise für ein gutes Refactoring-Tool, dass das Verschieben von Objekten, Methoden in andere Module (ähnlich wie in Eclipse unter Java) unterstützt wäre ich sehr dankbar

[stahli]

Hast Du wirklich "Erzeugen" genutzt (statt nur Compilieren)?
Weiterhin solltest Du Keine Kopien Deiner Ordner im Projektordner haben ("MyProject" und "MyProject-Kopie").
So etwas nimmt Delphi übel.

Refactoring ist natürlich in aktuellen Delphi-Versionen deutlich umfangreicher.
Wunder darf man aber nicht erwarten.
Dritttools kenne ich nicht.

[Nic2012]

Natürlich auch Compilieren, macht im Ergebnis aber keinen Unterschied.
Nein, es gibt im Projekt-Ordner keine Kopien. Das gesamte Projekt besteht aus einigen Dutzend Forms, DMs, und Units, aber nur bei diesem Modul gibt es nur sehr eingeschränkte Debug-Möglichkeiten, d.h. nur auf den letzten 1800 von insgesamt 10000 Zeilen.

[CCRDude]

Die Warnung mit den Projektkopien kann man noch globaler nehmen: sind die Unit-Namen recht eindeutig? Hat mat sowas wie FormUnitMain.pas in jedem Projekt, springt der Debugger gerne zur Anzeige mal in die falsche Datei (Stand: XE, bei D7 war das auch schon so).

Ich habe früher in jugendlichem Leichtsinn und unter D7 auch lange eine Unit mit noch mehr Zeilen gehabt, und Debuggen lief dort überall - die nachgefragte Obergrenze sollte es nicht geben (zumindest nicht bei 10k Zeilen - bei meinem Negativbeispiel hat die .pas 544KB, 13K Zeilen, die .dfm 2,4MB - das lief unter D7, danach habe ich die Funktionalität in kleine Klassen in kleinen Units aufgeteilt...).

[Uwe Raabe]

Ich habe hier Units mit bis zu 140.000 Zeilen (natürlich automatisch generiert) und da geht das Debuggen auch ganz hervorragend.

[Nic2012]

Danke für die zahlreichen Antworten.
Nein, Projektname bzw. die Namen der Forms, DMs und Units ist durchgehend eindeutig. Wie gesagt es ist nur diese DM. Kann es an der Vielzahl der eingebundenen Objekte ca. 200 liegen ?
Welche Erklärung gibt es, das nur knapp 20% der letzten Zeilen mit dem blauen Punkt (als potentiele Breakpoints) gesetzt ist und zumindest nur dort der Debugger halten kann ?

[lowmax_5]

Hast Du vielleicht mal Code aus dem Internet direkt in die Unit kopiert? Dann kann es an dieser Stelle auch zu Störungen kommen.

Dann schaue Dir doch die Stelle ab der die Breakpoints nicht mehr funktionieren mal genauer an. Ggf. Codeteil entfernen und prüfen, ob es dann funktioniert.

Ggf. ist auch eine Kommentarfunktion nicht korrekt gesetzt. Dieses kann auch zu einem Aussetzer führen...

[nahpets]

Hallo,

das von Dir beschriebene Problem kenne ich auch, aber auch bei deutlich kleineren Units und DMFs.

Einige Programme kann ich nicht Debuggen, andernorts läßt sich der Inhalt von Variabeln beim Debuggen nicht anzeigen (angeblich alles wegoptimiert). Einen Grund für dieses Verhalten von D7 kenne ich nicht, aber ich habe eine Vermutung, die ich bisher weder beweisen noch widerlegen konnte.

Bei Programmen, die viele Units (unterschiedlicher Quellen) nutzen, scheint das Problem häufiger aufzutreten, als bei 100%igen "Eigenbauten".

Mein Verdacht fällt hier auf die Kompilerschalter {$D+} und {$D-}.

Unabhängig von den Projekteinstellungen kann man diese Beiden ja auch im Quelltext unterbringen. Kommt der Kompiler an einem der beiden Schalter "vorbei", so scheint für ihn ab dort die entsprechende Bedingung zu gelten. Hierdurch kann es passieren, dass an beliebigen Stellen das Debuggen funktioniert oder eben auch nicht. Dies scheint sich aber nicht nur auf die Unit auszuwirken, in der der Schalter steht, sondern auch auf die Units, aus denen die Unit mit Kompilerschalter aufgerufen wird. Hierdurch scheint dann das Debuggen in Units ab oder bis zu bestimmten Stellen zu funktionieren oder halt auch nicht.

Bei Deinem konkreten Fall könnte es unter Umständen eventuell vielleicht (also eine extrem wage Vermutung) möglich sein, dass kurz vor der Zeile, ab der die Breakpoints setztbar sind, beim Kompilieren eine Unit aufgerufen wird, in der der Schalter {$D+} steht. Irgendwo davor wird vermutlich eine Unit kompiliert, in der der Schalter {$D-} steht und deshalb keine Debuginformationen vorhanden sind.

Aber: Nix genaues weiß man nicht.

Ab und an scheint es zu helfen hinter die Uses-Anweisungen zusätzlich ein {$D+} einzufügen. Manchmal hilfts, aber nicht immer.

Eventuell hast Du ja damit Glück.

[rwalper]

Hi, ich hatte bei D6 mal das gleiche Problem.

Probleme haben jene Zeilen bereitet, deren Zeilenende nur aus #10 statt #13#10 bestand. Ab der ersten dieser Zeilen, waren die Debug-Punkte "verrutscht".
Kontrolliere das doch einmal in einem Editor, der die Zeilenende-Zeichen anzeigt, z.B. Notepad++ (da steht dann LF statt CRLF).

[Nic2012]

Zitat:

Hast Du vielleicht mal Code aus dem Internet direkt in die Unit kopiert? Dann kann es an dieser Stelle auch zu Störungen kommen.

Dann schaue Dir doch die Stelle ab der die Breakpoints nicht mehr funktionieren mal genauer an. Ggf. Codeteil entfernen und prüfen, ob es dann funktioniert.

Oh, da sind zuviele Abhängigkeiten zu anderen Units vorhanden. Da müsste ich die ersten 80% vom Code entfernen. Wie gesagt nur die letzten 20% lassen sich debuggen.

Der gesamte Code dieser DM funktioniert fehlerfrei zur Laufzeit, aber eben keine Breakpoints. Ich habe nachgezählt aufgrund der TSmartQueries gehen mehr als 2500 Zeilen auf das Konto der Deklaration der Felder. Ist das zuviel für den Debugger ?

PS: {$D+} prophylaktisch hat nicht geholfen, obwohl einige 3rd-Party Units dabei sind, die {$D-} schalten.