4

Possible Duplicate:
Is there a Delphi option to ‘lock’ the design (layout) of a form against accidental changes?

We recently changed have changed from StarTeam to SVN, but we're having problems with our DFM files. It looks like Delphi changes the DFM files even though we're not actually changing the form.

For example: I open an existing file, I change the active tabsheet, save the file, change the tabsheet back to it's original state, and save it again. When I diff the two files, the PixelsPerInch, TextHeight, Top, and lots of other values have changed? A little sample of my code:

   PixelsPerInch = 96
      TextHeight = 13
      inherited PageControl1: TPageControl
        Top = 105
        Height = 629
        Margins.Left = 5
        Margins.Top = 5
        Margins.Right = 5
        Margins.Bottom = 5
        HotTrack = True
        inherited TabSheet1: TTabSheet
          Margins.Left = 5
          Margins.Top = 5
          Margins.Right = 5
          Margins.Bottom = 5

My question is: is there a way to let Delphi only change the DFM only if the form has changed? Now, we have conflicts when we Update in SVN all the time.

Community
  • 1
  • 1
Liezzzje
  • 430
  • 2
  • 6
  • 17
  • You've changed the form, or the .dfm wouldn't change. Changing the active tabsheet of a pagecontrol does change the form in memory and marks it as modified so the next time you save the file the .dfm will be saved to disk. If you hadn't changed anything nothing would get saved to disk; the .dfm file wouldn't be touched. – Ondrej Kelle Oct 16 '12 at 11:01

2 Answers2

8

This is just a consequence of how Delphi's form streaming mechanism works.

When you open a form in the Delphi designer, the .dfm file is used to create instances of each component on the form. In your case, the form designer will instantiate each of the objects in the .dfm file. Each property in the .dfm file will be read in.

Then, if you do anything in the designer that marks the form as having been modified, for example changing the active tabsheet, then the designer will re-create the .dfm file when you save. And it re-creates the .dfm file by asking the in-memory components to save themselves. This saving process makes no account of what the .dfm file on disk looks like. Each component just saves its properties as they are at that point in time.

So, in summary, there's really nothing you can do to change Delphi's behaviour. The best you can do is to work around it to minimise the impact.

If your forms have Scaled=True then you should make sure that all developer machines use the same font scaling. Otherwise when developer A saves at one font scaling, that .dfm file will be completely different from the one that developer B saves at a different font scaling. All positions will be altered. It sounds as though you have some developers that use 120dpi font scaling. And that's going to give you no end of grief.

If benign edits to the form file result in large changes, commit those changes. Once you have every developer machine configured the same way, you'll find things settle down. Those benign edits should no longer result in .dfm file changes.

This is just one of the occupational hazards of visual design with Delphi. You need to pay lots of care and attention to your .dfm files whenever you commit. I regularly find myself reverting changes to .dfm files from the Tortoise commit dialog. I also often elect to modify the .dfm file in a text editor rather than using the form designer!

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 3
    The last paragraph is so true. You should always pay attention to the dfm before commiting changes. – Tobias R Oct 16 '12 at 09:36
  • Indeed, there is one developer with a laptop with 120dpi font scaling. We altered this setting and his PixelsPerInch value is like ours, but still his TextHeight (=16) (and many other width/heigth/... values) are different . – Liezzzje Oct 16 '12 at 12:39
  • You need a restart for sure. Once you do that load up the form on that laptop, change something and save. If you get everyone on the same dpi it can be made to work. – David Heffernan Oct 16 '12 at 12:52
0

You will also see dfm changes if you have updated delphi version since that form was last saved. So, if you have an old form and check it out to make a minor change, you will see a number of other changes. Sometimes these are new properties introduced in the new delphi version, sometimes changes to the values. These also indicate pending changes yet unmade to forms that haven't been checked out. After upgrading delphi, you could check out every form, and immediately check it back in to record all those changes.

With visual design we like to create the form "just as we like it" then have delphi save all those changes. It quietly sets a lot of properties, but these may change as different developers work on the forms. If the setting is important - maybe form height and width - set it in the code. You will still see the property changes, but you will know it doesn't matter.

Patrick Moloney
  • 642
  • 5
  • 14