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

[haentschman]

Zitat:

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

@Embacadero: ...ist das sooo ein großer Aufwand das nach dem Alphabet, unhabhängig von der Position, zu sortieren und zu speichern?

[himitsu]

Da müsste man das vorher in eine Liste schreiben und erst am Ende in die DFM.
Zu viel Aufwand.

Es geht einfach in der Reihenfolge, wie es gefunden wird (RTTI).

Einige komponenten gehen auch davon aus, dass bestimmte Property zuerst geladen werden,
was dann bei Änderung der Reihenfolge knallt.
Aber hier sollten die Entwickler eh langsam mal lernen, dass man nicht ALLES sofort im SETTER behandelt, sondern beim csLoading das dan erst "einmal" im Loaded zu machen hat.




Nett ist auch, wenn man mit unterschiedlichen IDE-Versionen arbeitet. (z.B. noch das alte Delphi und Einige schonmal mit dem neuen Delphi)


Ich verwerfe sowas auch "meistens".
Bei kleinen Änderungen, lade ich dann nur das Gewollte hoch.

Bzw. bei großen Änderungen an der Unit dann auch mal sowas gleich mit (z.B. wenn sich an der DFM so viel geändert hat, dass Dieses eh nicht auffällt),
aber besser solche Änderungen als eigenen Commit, damit Sie bei Rückblicken (wann hatte sich was geändert) nicht störend einmischen (man die eine eigentlich geänderte Zeile nicht mehr sieht).



Natürlich könntest du nur beim Vergleichen, oder vor dem Commit einen Hook einsetzen, der die DFM sortiert, bzw. einen Comparer für DFMs hinzufügen, der es ohne Berücksichtigung der Reihenfolge vergleicht. (so ähnlich, wie es gern für XML Welche gibt, denen Formatierung und eventuell auch die Reihenfolge egal sind)

[Uwe Raabe]

Zitat von haentschman:

@Embacadero: ...ist das sooo ein großer Aufwand das nach dem Alphabet, unhabhängig von der Position, zu sortieren und zu speichern?

Das mag vielleicht möglich sein, aber es gibt auch Fälle, bei denen die Reihenfolge der Properties relevant ist. Beispiele aus der VCL sind TStandardColorMap, TActionManager, TMonthCalendar, TComboBoxEx, TComboBox. DevExpress hat da auch noch einige anzubieten.