DFM DIFF ... IDE oder Komponente speichert falsch?

[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?

[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.

[Rolf Frei]

Zitat von 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?

Das darf nicht alphabetisch gemacht werden! Die Reihenfolge muss vom Entwickler gesteuert werden können, da die Reiehenfogle der eingelesenen Porperties unter Umständenn voneinander Abhängig sind und das würde nicht mehr funktionieren. Ob ein Property in das DFM kommt oder nur unter bestimmten Umständen, wird durch den Entwickler der Komponente gesteuert und nicht durch EMB. Wenn da ständig irgendwelche Properties rein- und rausfliegen, liegt das an der DevEx Komponente, die das je nach Situation speichert oder eben nicht. Das hat nichts mit der IDE zu tun.

[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)