DFM DIFF ... IDE oder Komponente speichert falsch?

[haentschman]

Hallöle...

Es nervt ziemlich, gerade bei DevExpress, daß wenn man die Form speichert, u.a. die DFM Einträge "verschoben" sind.
Auch bei DevExpress:
Manchmal werden die Properties automatisch reingenommen, machmal wieder entfernt. Berühmt dafür:

Delphi-Quellcode:

DockedDockingStyle = dsNone
DockedLeft = 0
DockedTop = 0
DockingStyle = dsNone

Wer ist dafür zuständig. Die IDE oder die Fremdkomponente?

Jedes Mal den DIFF zeilenweise kontrollieren nervt.

...Luft abgelasssen.

[Sherlock]

DFMs sind ein steter Quell der Freude. Wir ignorieren eigenmächtige DFM Änderungen wie diese oder irgendwelche Datumsänderungen in entsprechenden Controls einfach per VCS. Nur wenn tatsächlich absichtliche Änderungen durch einen Entwickler vorgenommen wurden, wird dieses DFM committet, alles andere verworfen.

Sherlock

[Uwe Raabe]

Entscheidend für die Reihenfolge der Properties ist die Reihenfolge in der sie published sind.

Eine Möglichkeit für den Effekt den du da siehst wäre, wenn das Offsets Property in einem Vorfahren protected war und erst im Nachfahren published, jetzt aber schon im Vorfahren published ist. Solange du diese Änderung nicht im VCS übernimmst, wird dir das Diff erhalten bleiben.

Gemein wird es, wenn man die DFM mit unterschiedlichen Design-Packages öffnet (alt/neu). Dann geht es ständig hin und her.

[Sinspin]

Mit diesem Irrsinn sollten ja alle Nutzer der neueren Versionen schon Erfahrung haben.

Denn Emba selber macht es ja nicht besser! Diese Explizit* Einträge die die ganze Zeit auftauchen und wieder verschwinden sind die Pest!

Was ich bei DevExpress furchtbar finde ist, bei einigen Komponenten ein Teil der Daten Binär zu speichern. Oder keinen Zugriff zur Laufzeit zu ermöglichen. Die TdxBar ist darin Spitze.
Oder TcxGrid wenn man den InplaceEditor verwendet. Das Ding ist ja schon zur Designzeit ein absolutes Verbrechen.

[mjustin]

Zitat von Sinspin:

Denn Emba selber macht es ja nicht besser! Diese Explizit* Einträge die die ganze Zeit auftauchen und wieder verschwinden sind die Pest!

Gegen die Explicit* Einträge hilft der DDevExtensions Experte (Seite "Form Designer", "Do not store the Explicit* Properties into the DFM").

[haentschman]

Zitat:

Nur wenn tatsächlich absichtliche Änderungen durch einen Entwickler vorgenommen wurden, wird dieses DFM committet, alles andere verworfen.

...das mache ich aus so. Das entbindet dich aber nicht von dem Anschauen der jeweiligen Zeile...könnte ja wichtig sein.

[Sherlock]

Zitat von haentschman:

Zitat:

Nur wenn tatsächlich absichtliche Änderungen durch einen Entwickler vorgenommen wurden, wird dieses DFM committet, alles andere verworfen.

...das mache ich aus so. Das entbindet dich aber nicht von dem Anschauen der jeweiligen Zeile...könnte ja wichtig sein.

Ich bin da gnadenlos auf Krawall gebürstet, wenn es nach einem Pull knallt, weil die DFM Änderung doch Absicht war, aber vergessen wurde reinzustellen, muss ich mit diesem Sonderfall leben, aber ich vergeude keine Zeit mit DFM Kontrolle (mehr).

Sherlock