Keine blauen Punkte

[freimatz]

Hallo zusammen,
ich habe mal wieder das Problem, dass beim Debuggen keine blauen Punkte da sind. Das habe ich oft, bekomme es aber jedesmal irgendwie wieder hin. Nun habe ich gerade keine Ideen mehr.

Projekt A, mit einem einzigen Formular in unit B. Darin wird etwas in unit C1 aufgerufen. A und B hat blaue Punkte, C1 jedoch nicht. Alle dcus gelöscht, Delphi neu gestartet, Build, Clean, ...

Nun neue unit C2 in Delphi anlegt, diese wird nun auch von B aufgerufen. Darin ist ein Aufruf einer Methode 'nop' in unit D. Blaue Punkte in A, B und D, nicht aber in C2. Debugger bleibt in einem Breakpunkt in D auch stehen.

Der Callstack ist wie folgt:
u_LowUtils.nop
pos_Application.pos_Application
:009b5c1a pos_Application + $E
:004099c4 @StartExe + $44
:770ffa29 KERNEL32.BaseThreadInitThunk + 0x19
:775175f4 ntdll.RtlGetAppContainerNamedObjectPath + 0xe4
:775175c4 ntdll.RtlGetAppContainerNamedObjectPath + 0xb4
(Die erste Zeile ist unit D)

Ideen?

[scrat1979]

Die entsprechende Unit mal mit einem geeigneten Editor auf korrekte Zeilenumbrüche testen.

Dies sei wohl oft was Problem.

[freimatz]

Sollte wohl nicht das Problem sein, wenn ich eine neue Datei anlege. Trotzdem danke.
Inzwischen habe ich etliches gelöscht u.a. die *.dproj. Nachdem ich diese wieder zu compilieren geschafft habe sind die blauen Punkte da.

Es gibt Tage da könnte ich Delphi ... :wall: :feuerchen:

[jaenicke]

Zitat:

Zitat von freimatz (Beitrag 1476472)

Sollte wohl nicht das Problem sein, wenn ich eine neue Datei anlege. Trotzdem danke.
Inzwischen habe ich etliches gelöscht u.a. die *.dproj. Nachdem ich diese wieder zu compilieren geschafft habe sind die blauen Punkte da.

Meistens ist das eine Einstellung eben genau in der .dproj Datei. Die genaue Ursache sollte sich beim Vergleich der neuen funktionierenden Datei mit der alten Version aus dem Repository finden lassen. Bzw. wenn du eine der letzten Versionen auscheckst, sollte sich ja auch zeigen wo der Unterschied lag.

Es macht auch Sinn beim Einchecken der .dproj Datei die gleiche Sorgfalt wie für andere Quelltextdateien walten zu lassen und jede Änderung vor dem Einchecken zu überprüfen. Leider werfen manche diese einfach ohne Prüfung ins Repository, was dann auch mal Probleme wie dieses verursacht.

[freimatz]

Ja, ich werde versuchen mehr Sorgfalt walten zu lassen.

Es wäre jedoch schön wenn Delphi diese Sorgfalt walten lassen würde...

Eine ältere Version habe ich ausgecheckt, da war das Problem das gleiche.
Ein Vergleich der neuen mit der alten ist nutzlos, weil sich nahezu alles geändert hat.
In der Firma benutzen wir den Uwe Raabe's ProjectMagicion. Den habe ich mir jetzt auch hier installiert.
(Danke Uwe, aber schon traurig, dass man sowas braucht.)

[jaenicke]

Ja, mich ärgert das auch, ich will das auch gar nicht gutheißen oder schönreden.

Da wir in unsere Dateien aber grundsätzlich nur gewünschte Änderungen einchecken, gibt es mit den .dproj Dateien bei uns eben relativ wenig Probleme. Das behebt zwar nicht die Ursache, aber es ist eine Lösung, mit der wir gut leben können...

[freimatz]

Ja, ok. Danke.

[himitsu]

Jo, gerade das mit den DPROJ ist echt nervig ... sändig unterschiedliche reihenfolgen und manchmal räumt öffnen und schließen+speichern alles komplett um.

[hoika]

Hallo,

Zitat:

In der Firma benutzen wir den Uwe Raabe's ProjectMagicion.

Vielleicht ist ja auch Uwe Schuld ;)

Nein, im Ernst!.
Wir checken mitterweise die dproj-Dateien nur im Ausnahmefall ein.

Xml-Diff zu lesen ist viel zu anstrengend.

[Sisko]

Ich habe da noch einen Nachfrage:
Die fehlenden blauen Punkte kenne ich leider auch zu genüge, besonders unter Win64. Auch die Sache mit den Line-Endings in den Unit-Dateien ist mir bekannt.
Aber WIE kann ein Eintrag in der DPROJ-Datei zu so einem verhalten führen?
Mir ist schon aufgefallen, dass beim Einsatz von Build-Events in der DPROj-Datei selbst gemischte Lineendings vorkommen, aber kann dies wirklich zu einem Problem führen?

Ich setzt übrigens auch den ProjectMagician von Uwe ein - ein wirklich SEHR nützliches Plugin.