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

Heat

The creation order is determined by the order of appearance in the dfm file, so by process of elimination these must specify the z-order – Florin

I've made a short YouTube video which hope makes both the question and answer on this question really clear, the only thing it really adds to hvd's answer is that it also applies to frames as well as forms. – Iconoduly

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.

Crinkle

+1. I've never seen this syntax in DFM files, interesting to read both the question and answer. – Rosewater

Thanks. I will have to update the parser then (alas). I did try to remove the numbers from the DFM but they automagically reappeared after reloading the app in the IDE. They were different aftre that, as well as the order of the components in the DFM files. – Heat

Just a quick follow up for people who want to do the same thing: we abandoned the Colibri parser - too much work to adapt it. Since we are not interested in the ways the objects are nested we just parse ASCII text blocks from 'object'/'inherited' to 'end', process these blocks and write them back out. – Heat

What I don't like about this answer is that you don't explicitly say what the values mean. They specify z-order right? So say so. – Florin

@DavidHeffernan They don't necessarily mean that. They mean component index. For TWinControls, that corresponds to Z-order, and I did mention "If they're TWinControl descendants, that means they differ in whether X is shown over Y, or Y over X." Otherwise, it's more complicated. Non-windowed controls (say, TLabel) always get a component index lower than any windowed control in the same parent, but I don't want to rule out a parent that paints non-windowed children on top of windowed children (it should be possible), and for non-controls, the component index exists too but is mostly unused. – Crinkle

That's the exact information that needs to be in the example. Please can you edit. This is a valuable answer to a question that will be asked again and again. It would be valuable to make it better. – Florin

@DavidHeffernan Something like this? – Crinkle

That's better, but I'm still a little confused. Creation order is, I believe determined by the order in which the objects appear in the .dfm file. – Florin

@DavidHeffernan That's mostly true: the blocks in DFM files are processed in the order in which they're encountered. object and inline blocks in DFM files cause objects to be created, and so the objects will be created in the order in which they appear in the DFM file. inherited blocks, however, modify objects that have already been created, usually as part of the streaming of a base class's DFM, so in the above, TC.Create first reads A.dfm and creates X, then it reads C.dfm, creates Y, and modifies X. Even though X appears later, it is created first. – Crinkle

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.

Signor