41

We've noticed that when checking in updates, our .DFM files have added ExplicitWidth and ExplicitHeight properties - but we don't know why.

My questions are:

  • What are these properties for?
  • Why are they automatically added by Delphi?

Below is an example showing the added ExplicitWidth property:

object Splitter2: TcxSplitter
    Left = 0
    Top = 292
    Width = 566
    Height = 8
    Cursor = crVSplit
    HotZoneClassName = 'TcxXPTaskBarStyle'
    AlignSplitter = salBottom
    Control = BottomPanel
    Color = clBtnFace
    ExplicitWidth = 8
end
Pauk
  • 2,623
  • 3
  • 26
  • 28
  • What does the Delphi documentation say ? :P – mjn Mar 19 '10 at 11:52
  • 15
    Are you seriously suggesting I RTFM? Now where's the fun in that? And I should add I'm using Delphi 2007 so I'm still *waiting* for the *Help* to load. I thought it would be quicker to ask on Stack Overflow! – Pauk Mar 19 '10 at 11:59
  • 2
    @Mjustin, the help says this: *ExplicitWidth is a read only property used internally by Delphi. Use Width in applications, thereby allowing read and write access.* http://docwiki.embarcadero.com/VCL/en/Controls.TControl.ExplicitWidth – Rob Kennedy Mar 19 '10 at 18:54
  • 3
    It so happens I **did** RTFM. All I got was the following: _"This is ExplicitWidth, a member of class TControl."_ So thanks Rob. :) – Disillusioned Aug 14 '13 at 14:50
  • 2
    all too often RTFM is an exercise in deciphering a vague, poorly written manual. Large companies farm this out to China so you often have a Chinese person, who knows very little English, typing up these manuals. I came here on a search for same problem. I use C++ Builder in the office and at home office and when I copy code back and forth, this happens to me too. I don't change the achors. One IDE puts them in and the other takes them out. – Eric Jul 18 '14 at 20:21

4 Answers4

40

With DDevExtensions you can disable storing these properties in the dfm:
http://andy.jgknet.de/blog/?page_id=10

Adds Explicit* property remover to keep DFM files compatible to older Delphi versions

André
  • 8,920
  • 1
  • 24
  • 24
  • 10
    +1. I don't use it for compatibilty reasons but just to keep my DFMs smaller and the source control diffs less cluttered. – Uli Gerhardt Mar 19 '10 at 12:25
  • 3
    I like this, since like Ulrich, it removes it from bugging us on source code updates. Wish I could split the answer between both this and JamesB's answer! – Pauk Mar 19 '10 at 15:45
  • Thing is unless everyone who'll edit your dfm has DDevExtensions installed too, and the option turned on, you'll end up with more differences every time they save the file. – SoftDeveloper Apr 30 '15 at 11:23
  • Perfect solution. Extension moved to https://www.idefixpack.de/blog/ide-tools/ddevextensions/ – ralfiii Jan 12 '23 at 10:31
31

From Googling....

Original article can be found here.

The Explicit properties remember the previous bounds of a control before the Align or Anchor properties are changed from their defaults.

The only time the Explicit properties are not written is when the Align property is set back to its default value of alNone.

This is when the Explicit properties are actually used by the control to reset its bounds to what it was previously.

James
  • 9,774
  • 5
  • 34
  • 58
  • 3
    They're the dimensions that you *explicitly* gave them, as opposed to the dimensions that they acquired *implicitly* due to alignment or anchoring. They're not necessarily the *original* dimensions, which you might have changed between the time you created the control and the time you set its alignment. – Rob Kennedy Mar 19 '10 at 14:46
  • 14
    This sounds plausible, but it isn't what actually happens: In my experience the Delphi IDE switches between storing the same values in Left/Right/Width/Height an their ExplicitXxx counterparts every time the form gets written to the .dfm. The same applies to the ItemHeight property of a TComboBox which changes between 0 and 13 and back all the time. It gets quite annoying when my source control wants to post changes to the .dfm all the time when nothing actually has changed. – dummzeuch Mar 19 '10 at 18:55
  • 5
    @dummzeuch many Delphi versions exhibit the behaviour you mention. It is irritating as it clutters the diffs in version control history. – Jeroen Wiert Pluimers Jan 29 '15 at 12:01
  • Yes, the new Explicit* properties are automatically being written regardless of whether or not I have changed the Align or Anchor property. It contains Explict* = 0, and the version control history now shows meaningless changes. This is exactly the kind of thing that makes using Embarcadero annoying. – Bizmarck Jan 05 '16 at 19:53
0

Delphi adds value of published properties to DFM file only when its value different from default.

For example:

property ExplicitWidth: Integer read FExplicitWidth write FExplicitWidth default 1;

If ExplicitWidth value is not 1 then it will be written to the DFM. When the "default" is not defined then any value will be written to the DFM.

TcxSplitter is not standard Delphi component, you'd better ask its author about the purpose of the properties.

  • 6
    I just listed TcxSplitter as an example that I had to hand. It most commonly happens with TForm. – Pauk Mar 19 '10 at 11:39
0

I encounter a lot of noise from random (dis)appearances of these:

ExplicitLeft = 0
ExplicitTop = 0
ExplicitWidth = 0
ExplicitHeight = 0

So I wrote a tool that removes only these (all 4 exist and are 0) from DFM files:

https://github.com/gonutz/dfm_clear_explicit_zeros

gonutz
  • 5,087
  • 3
  • 22
  • 40