The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,735 other followers

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:

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



7 Responses to “Please review your DFM files before you commit to version control”

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

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

  3. quantendreher said

    Same problem with xe5 – sizes and imagelists are modified by open a file.

  4. 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?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: