Does the order of properties in DFM file matter?

Question

Could a not-standard order of the properties cause any problem?

For example, the IDE stores a TButton component in the DFM file as follows:

  object Button1: TButton
    Left = 288
    Top = 160
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
    OnClick = Button1Click
  end

If I manually change the order of the properties, could this cause any problem?

  object Button1: TButton     
    OnClick = Button1Click
    Left = 288
    Top = 160
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
  end

Order doesn't matter, but the IDE will revert them to the original order the next time the form is edited, so it won't matter anyway. You could have tested this yourself in about 60 seconds by creating a new VCL app, dropping a button on it, saving it, and then editing the DFM with Notepad and reopening it in the IDE. — Ken White, Oct 16 '19 at 12:32
Sometimes order does matter! See my answer below for some examples. — Uwe Raabe, Oct 16 '19 at 13:21
@Ken White that would only give the answer in a specific case... — Fred vdP, Oct 16 '19 at 14:11
For sure there are cases where order matters. Not the properties listed here though. — David Heffernan, Oct 16 '19 at 14:20

score 6 · Accepted Answer · answered Oct 16 '19 at 13:20

There seem to be cases where the order actually matters!

For examples see the comments in the published section of TStandardColorMap, TActionManager, TActionClientItem, TTabControl, TTreeView, TMonthCalendar, TDateTimePicker and TComboBoxEx (to just name a few from Vcl), where the order of published properties is relevant.

As the order of properties in the DFM determines the order the published properties are set, any other order may affect the values of the properties after reading a component from the DFM.

The fix-up mechanism mentioned by MartynA in another answer is not used for these sort of properties.

MartynA · Answer 2 · 2019-10-16T13:23:36.757

0

It makes no difference afaik.

The TReader class is responsible for handling the reading of component properties from the DFM stream. This operates by creating a "fix-up list" of property values read from the stream, which is used, after the entire component has been read in, to set the component's properties. See the Streaming chapter in Delphi Component Design by Danny Thorpe (ISBN 0-201-46136-6) for much fuller details any why it was designed the way it is.

I see Uwe Raabe has added an answer, and he's usually right ime.

edited Oct 16 '19 at 13:23

answered Oct 16 '19 at 12:16

MartynA

30,454
4
32
73

1

The fixup list applies to properties that are component pointers, not to properties that are non-pointers. If a property refers to an external component that hasn't been streamed yet, the reader remembers to go back and fix that reference at a later time. That is not the case with non-pointer properties, like strings and integers and such, they are streamed immediately and as-is. – Remy Lebeau Oct 16 '19 at 14:42
@RemyLebeau: THanks but that's why I referred to D Thorpe's book. – MartynA Oct 16 '19 at 15:14

score -1 · Answer 3 · answered Oct 16 '19 at 10:55

-1

As far as I know order of properties in DFM file doesn't matter.

answered Oct 16 '19 at 10:55

SilverWarior

7,372
2
16
22

Does the order of properties in DFM file matter?

3 Answers3