Breakpoints funktionieren nicht -> DSK löschen

[himitsu]

Zitat von Rolf Frei:

So habe ich bisher keine unerklärlichen Probleme mit den Breakpoints gehabt.

Nja, Probleme hast in dem Sinne schon, dass du erst den Build machen mußt, um die "richtigen" DCUs zu bekommen.
Zwischen Release und Debug geht es ja noch, aber zwischen unterschiedlichen Platformen und Compilern raucht es besonders schön.

Darum gibt es ja den Weg über die verschiedenen Verzeichnisse, damit beim Umschalten sofort alles da ist.
Das kann man sogar noch weiter treiben, also inkl. Compiler/Delphi-Version, wenn man mit mehreren Delphis arbeitet.
Sowas ist vor allem wichtig, wenn man mehrere Versionen erzeugen will (Win32, Win64, Android, iOS, Delphi 7, XE, 10.3, 10.4, usw.)
z.B. .\_DCU_$(ProductVersion)_$(Platform)_$(Config) vom Projekt aus, oder mit absolutem Pfad ala C:\DCUs\$(ProductVersion)_$(Platform)_$(Config)

Aber du kannst dir das auch nur in ein Unterverzeichnis .\_DCUs reinmachen, dann brauchst nur dieses Verzeichnis zu löschen und alles ist sauber, anstatt zwischen den PAS überall die DCUs zu suchen.




Ein Problem gibt es, was nicht auftritt, wenn die DCUs neben den PAS liegen.
Mehreren Projekte, welche die selben Ausgabeverzeichnisse nutzen (womöglich in einer Projektgruppe), aber wo in den Pojekten gleichnamige Units vorkommen.

[Uwe Raabe]

Zitat von himitsu:

Mehreren Projekte, welche die selben Ausgabeverzeichnisse nutzen (womöglich in einer Projektgruppe), aber wo in den Pojekten gleichnamige Units vorkommen.

Dafür kann man in den Ausgabepfaden noch den $(SanitizedProjectName) einsetzen, dann bekommt jedes Projekt seine eigene DCU-Verzeichnisstruktur.

Code:

.\dcu\$(SanitizedProjectName)\$(ProductVersion)\$(Platform)\$(Config)

[TigerLilly]

Bis jetzt ist es nur ein einziges Projekt, bei dem es das Problem gibt. Alle anderen funktionieren wie gewünscht. Einmal F9, Breakpoints funktionieren + dann nicht mehr. Es genügt "Alles schließen", neu öffnen und die Breakpoints gehen wieder. Was kann das sein?

[TigerLilly]

Ich sollte präziser sein. Also: Das Projekt ist Teil einer Projektgruppe. Öffne ich das Projekt und nicht die Projektgruppe, funktioniert alles wie gewünscht.

[Uwe Raabe]

Die Breakpoints werden in der DSK-Datei des Projekts oder der Projektgruppe gespeichert, je nachdem was man öffnet.

Das macht es ja auch so schwierig, die Breakpoints z.B. nach einer Formatierung der Sourcen wieder korrekt zu setzen. Neben der DSK-Datei des aktuellen Projekts oder der Projektgruppe, kann eine Unit ja auch in anderen Projekten verwendet werden, zu denen es Breakpoints in deren DSK-Dateien gibt. Von denen weiß man in der Regel aber nichts im aktuellen Projekt.

Ich erwähne das u.A. auch auf einen Beitrag von @stahli zu seinem UnitOptimizer, in dem er sagt:

Zitat:

Also die Widerherstellung der Bookmarks und Breakpoints nach der Codeformatierung habe ich im Griff.

Das wage ich zu bezweifeln.

[TigerLilly]

Hmm. Dann wäre eine mögliche Erklärung für mein Problem, dass die Breakpoints aus der DPOJ mit denen in der DSK kollidieren? Ich weiß nicht, ich lass mir einreden, wenn Breakpoints auf andere zeilen rutschen etc, aber das gar nichts mehr geht, wundert mich schon.

Aber dann lösche ich mal DPROJ und DSK + öffne das projekt nur mehr aus der Projektgruppe. mal sehen.

[stahli]

Zitat von Uwe Raabe:

Ich erwähne das u.A. auch auf einen Beitrag von @stahli zu seinem UnitOptimizer, in dem er sagt:

Zitat:

Also die Widerherstellung der Bookmarks und Breakpoints nach der Codeformatierung habe ich im Griff.

Das wage ich zu bezweifeln.

Hmm, ich habe schon aufgehorcht, als ich hier gerade mit las.
Eine solche Unterscheidung war mir nicht bekannt.

Ich arbeite aktuell in einer Projektgruppe. Wird eine solche eigentlich nicht immer übergeordnet erzeugt - auch wenn nur ein Projekt bearbeitet wird?

Ok, es kann sein, dass es Konstellationen gibt, bei denen ich die Breakpoints noch nicht wieder herstellen kann.
Evtl. müsste ich nochmal nachbessern oder die Funktionalität auf den Projektgruppenfall beschränken.

Augenscheinlich hat bei mir die Funktion aktuell immer funktioniert.
Aber die ToolsAPI sind schon SEHR unübersichtlich.

Ich werde das heute Abend mal testen.

[Uwe Raabe]

Zitat von stahli:

Ich arbeite aktuell in einer Projektgruppe. Wird eine solche eigentlich nicht immer übergeordnet erzeugt - auch wenn nur ein Projekt bearbeitet wird?

Es wird in der Tat eine virtuelle Projektgruppe erzeugt, wenn du direkt ein Projekt öffnest. Diese wird aber erst gespeichert, wenn du das explizit auswählst. Die IDE unterscheidet hier schon, ob du eine Projektgruppe oder ein Projekt öffnest und stellt das auch entsprechend in der Titelleiste dar.

Du kannst das ja mal ausprobieren. Die Breakpoints und auch die geöffneten Dateien sind anders wenn du ein Projekt öffnest, als wenn du eine Projektgruppe öffnest die das Projekt enthält. Grund sind die unterschiedlichen DSK-Dateien für den jeweiligen Fall.

Wird nur ein Projekt und keine Projektgruppe geöffnet, sollte IOTAModuleServices.MainProjectGroup übrigens ein nil zurück liefern. Das gerade aktuelle Projekt ist dann über IOTAModuleServices.GetActiveProject zu ermitteln.

Wir hatten vor einiger Zeit eine Diskussion u.a. mit Marco Cantú darüber, wie man den Delphi-Formatter dazu bringen kann die Breakpoints zu berücksichtigen. Die festgestellten Probleme haben dann dazu geführt das Feature erst wieder auf Eis zu legen.

Die unterschiedlichen DSK-Dateien waren aber nicht das einzige Problem. Was macht man z.B. wenn eine Zeile mit Breakpoint gesplittet oder zusammengeführt wird?

[stahli]

Also ich ziehe über die IOTA-Funktionen die Breakpunkte heraus, die zur aktuellen pas-Datei gehören.
Im Quelltext setze ich Marker, die ggf. mit verschoben werden.
An den Marker-Stellen stelle ich Breakpoints wieder her.

Gleiches mit Bookmarks und der Cursorposition.

Das ist ziemlich aufwendig (aufwendiger als es sich anhört ) aber funktioniert augenscheinlich gut.

Kann natürlich sein, dass es Fälle gibt, die so nicht abgedeckt werden. :-/


Was garantiert ein Problem ist, sind Breakponts in Units, die von anderen Projekten gesetzt wurden. Die kennen dann natürlich keine Quelltextverschiebungen. Solche Sonderfälle (die sicherlich auch selten sind) wird man wohl so hinnehmen müssen...

(Wobei ich mich frage, warum die IDE so kompliziert arbeitet. Sicherlich aus historischen Gründen.)


kurzes Nebenthema:
Bei Interfaces, die projektübergreifend genutzt werden, werde ich Änderungen nachverfolgbar machen. Wird also in Interface IPerson die Property Vorname in FirstName umbenannt, werden alle Klassen-Eigenschaften des aktuellen Projektes sofort umbenannt.
Wird die Unit mit dem Interface auch in anderen Projekten anderer Projektgruppen genutzt, werden auch deren Klassen-Eigenschaften bei späterer Bearbeitung entsprechend angepasst.
Dazu werden entsprechende Änderungsinfos hinterlegt.

Bei projektgruppenübergreifenden Breakpoints wird das aber so kaum möglich sein.

[dummzeuch]

Zitat von stahli:

Also ich ziehe über die IOTA-Funktionen die Breakpunkte heraus, die zur aktuellen pas-Datei gehören.
Im Quelltext setze ich Marker, die ggf. mit verschoben werden.
An den Marker-Stellen stelle ich Breakpoints wieder her.

Gleiches mit Bookmarks und der Cursorposition.

Das ist ziemlich aufwendig (aufwendiger als es sich anhört ) aber funktioniert augenscheinlich gut.

Das ist definitiv besser als das der Formatter in GExperts macht. Der liest lediglich die Zeilennummern aus, formatiert und setzt anschließend die Breakpoints in dieselben Zeilen. Das passt natürlich nicht mehr, wenn sich Zeilen verschoben werden. Dasselbe passiert für Bookmarks. Trotzdem war das schon ein grosser Fortschritt gegenüber vorher, da wurden sowohl Breakpoints als auch Bookmarks einfach gelöscht. (Man muss sich auch mal selbst loben. )

Aber wo wir gerade über Code Formatting reden: Kann Deiner auch nur den aktuell markierten Bereich formatieren? Das ist definitiv ein Feature, das sehr nützlich wäre, wenn man z.B. das Format der Unit beibehalten will, aber den gerade bearbeiteten Bereich (z.B. eine neue Procedure) formatieren will (damit man das nicht manuell manchen muss).

Puristen werden jetzt natürlich aufheulen und sich beschweren, dass dann ja die Unit unterschiedliche Format-Stile enthält, aber ich sehe das pragmatich: Besser unterschiedlich formatiert als einen Bug übersehen, weil man manuell formatiert. (Der Klassiker: if/then/while Blöcke falsch eingerückt und schon passt die Formatierung nicht mehr zur Programmlogik.)