Please review your DFM files before you commit to version control
Posted by jpluimers on 2015/10/22
Recently I bumped into it again with one of the more current Delphi XE* versions and Delphi 2007: the IDE changing the DFM files without reason.
This time it was in a multi-team environment with many branches and DFM merge hell.
A few examples of properties and components getting changes:
- The Explicit* properties on components not using either Align or Anchors (unlike the article from JED Software: D2006: What on earth are these Explicit* properties in my DFM suggests), often compound components like TabSheet, most often with useless documentation and these values:
- ExplicitLeft = 0
- ExplicitTop = 0
- ExplicitWidth = 0
- ExplicitHeight = 0
- TImageList property Bitmap.
Warren P suggests to review your DFM changes before committing to version control and I completely agree: it is the only way to ensure they are indeed unwanted changes.
There are some stop-gab things you could try, but these only partially help
- Eric Grange uses a Resource based ImageList with design time editors. I wish that was open source, and I’m not alone on this (:
- André Mussche suggests to use DDevExtensions to switch of saving Explicit* properties but that kills all of them, including the ones you need.
–jeroen
via:
The Wiert Corner - irregular stream of stuff 
Catz said
afaik there is no such thing as an “Explicit* property that you need”. Without them, you only may loose some comfort when flipping the align property, right? In our team we got rid of those altogether using DDevExtensions as mentioned.
jpluimers said
Since the documentation on them is so thin, I don’t know. I wish someone could really dig into this and assure what can/can’t be done with these properties.
Catz said
I always took the fact that Explicit* properties occasionally change after resaving a form without touching the form designer (just minor change to the pas file) as strong indication that the implementation of this feature is just buggy. I remember reading that the implementation can not simply be fixed because of a flaw in the design. Unfortunately I am unable to provide a link, I can’t find it anymore.
jpluimers said
I totally agree with you. The design is flawed. They can’t fix it, because they made it in the product without properly thinking the design through.
Steven Kamradt said
I prefer keeping my imagelists on a separate datamodule to help promote sharing and to also reduce the DFM noise. I have also loaded them after the fact from a stream, more to allow for “theme” changes, but it also has the advantage of reducing the overall exe size (images were actually png files combined into a zip file and un-compressed into memory at program start up).
That being said, I never commit a .DFM so that ONLY the changes specific to what I’m trying to do make it into the check in. This also makes things a little easier to merge. Nothing worse than a merge conflict only because some bitmap property got modified several times by unrelated changes.
quantendreher said
Same problem with xe5 – sizes and imagelists are modified by open a file.
jandoggen said
Add to the list things like “ReportDocument.CreationDate” (in this case from a DevExpress component). But I don’t see a real issue here. Doesn’t anyone always review the modified files before committing (and look at the actual differences) when there’s an unexpected file in there?