Strange [number]s in Delphi DFM files - origin and necessity?

Question

I need to change a large number of Delphi components defined in one package to similar ones in another package. Much of the grunt work can be done by replacing text (component types and properties) in the DFM files - saved as text of course.

I have searched Stackoverflow and Google and am now adapting the Felix Colibri DFM parser from http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html

I come across a 'feature' in the DFM files that the parser chokes on: [number]s after the type specifications like this:

inherited DialoogEditAgenda: TDialoogEditAgenda
  ActiveControl = PlanCalendar
  Caption = 'Agenda'
  [snip]
  inherited PanelButtons: TRzPanel
    Top = 537
    [snip]
    inherited ButtonCancel: TRzBitBtn [0]  <== *here*
      Left = 852
      [snip]
    end
    object CheckBoxBeschikbaarheid: TRzCheckBox [1]  <== *here*
      Left = 8
      [snip]
    end
    inherited ButtonOK: TRzBitBtn [2]  <== *here*
      Left = 900
      [snip]
    end
  end
  inherited PageControl: TRzPageControl
    Left = 444
    [snip]
  end
  object PanelBeschikbaarheid: TRzSizePanel [2]  <== *here*
    Left = 967
    [snip]
  end
  object PanelScheduler: TRzPanel [3]  <== *here*
    Left = 23
    Top = 22
    [...]

Many of these DFMs are heavily inherited (I had to adapt Colibri's code for that already), but a small test app with inheritance failed to produce the [number]s in the DFM.

My question before having to extend the parser code: does anyone know where these [number]s come from and consequently, can I maybe remove them before parsing the DFM files?

Thanks

Jan

Answer 1

Those numbers aren't completely useless. Let's say you have classes TA, TB and TC, and TB and TC both derive from TA. The DFMs look like:

object A: TA
  object X: TX
  end
end

inherited B: TB
  object Y: TY
  end
end

inherited C: TC
  object Y: TY [0]
  end
  inherited X: TX [1]
  end
end

B and C differ in that the order of their X and Y subcomponents is reversed. The precise meaning of subcomponent order depends on the components (see below), but most notably, if they're TWinControl descendants, or they are both TControl descendants that do not derive from TWinControl, that means they differ in whether X is shown over Y, or Y over X.

Removing these numbers may change the forms, so you shouldn't blindly do it. However, depending on your goal, you may be able to modify the parser (source code appears to be available) to simply skip over the numbers.

The relative order of components generally does not generally matter much, but there are a few exceptions. To explain in some more detail:

For normal controls, the subcomponents start with (1) TControl descendants that do not derive from TWinControl, then (2) TWinControl descendants, finally (3) any non-TControl components. In each of these, the relative order of components is adjustable: for controls, the "Bring to front" and "Send to back" move the control as far as possible, with the limitation that a non-TWinControl can never be put after a TWinControl. For non-controls, the (slightly misnamed) "Creation order" option allows you to change the order. So, let's say you have two labels (A and B), two edit controls (C and D), and a dataset and data source (E and F), you can get the order to be for example, ABCDEF, BACDEF, ABDCFE, but not ACBDEF.

That order is preserved when saving to a DFM file: when visual inheritance is not used, components simply get saved and re-loaded in order. When you do use inheritance, the DFM files get processed base to derived, so in the above case, when TC is created, its X member is always created before its Y member. The [0] and [1] are needed to tell the Delphi RTL to fix up the order afterwards, in those cases where the component order matters.

What the component order actually does depends on the component type. As the "Bring to front"/"Send to back" names suggest, controls use the component order to specify the Z order. For other component types, it means whatever the component wants it to mean. For example, menus can use the component order to specify the order of their menu items (top to bottom). Toolbar controls can use the component order to specify the order of the toolbar buttons, even when those toolbar buttons aren't themselves controls. Data sets use the component order to specify the field order, and thereby also the default order of columns in a TDBGrid.

Answer 2

I have recently written a DFM parser, it supports these types of indices. It is written in Go and produces DFM files that look just like Delphi's.

https://github.com/gonutz/dfm

It was tested against RAD Studio source files and our own production code and it parses all and generates the files byte for byte. The aim was to have an easy way to change DFM trees and produce output that looks like it was created by RAD Studio.