Delphi DFM文件中奇怪的[number]s-起源和必要性？

我需要将一个包中定义的大量Delphi组件更改为另一个包中的类似组件。 很多繁重的工作都可以通过替换DFM文件中的文本（组件类型和属性）来完成——当然可以保存为文本

我已经搜索了Stackoverflow和Google，现在正在改编Felix Colibri DFM解析器

我在DFM文件中遇到了一个“特性”，解析器在类型规范之后阻塞了它：[number]s，如下所示：

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
    [...]

继承的DialogEditAgenda:tDialogEditAgenda ActiveControl=PlanCalendar 标题=‘议程’ [剪报] 继承的面板按钮：TRzPanel Top=537 [剪报]

---

继承的按钮取消：TRzBitBtn[0]这些数字并非完全无用。假设您有类

TA

、

TB

和

TC

，以及

TB

和

TC

都来自

TA

。DFMs看起来像：

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

和

C

的不同之处在于它们的

X

和

Y

子组件的顺序相反。子组件顺序的确切含义取决于组件（见下文），但最值得注意的是，如果它们是

TWinControl

子体，或者它们都是

t控件

的子体，而不是派生自

TWinControl

，这意味着它们在

X

是否显示在

Y

上有所不同，或者

Y

超过

X

删除这些数字可能会改变表格，所以你不应该盲目地这样做。但是，根据您的目标，您可能可以修改解析器（源代码似乎可用）以跳过数字

组件的相对顺序通常并不重要，但也有一些例外。要更详细地解释：

对于普通控件，子组件从（1）不是从

TWinControl

派生的

TControl

子组件开始，然后是（2）TWinControl子组件，最后是（3）任何非

TControl

组件。在每一种情况下，组件的相对顺序都是可调的：对于控件，“向前移动”和“向后发送”将控件移动到尽可能远的位置，但限制是非

TWinControl

不能放在

TWinControl

之后。对于非控件，（名称稍有错误）“创建顺序”选项允许您更改顺序。因此，假设您有两个标签（A和B），两个编辑控件（C和D），以及一个数据集和数据源（E和F），您可以获得顺序，例如ABCDEF、BACDEF、ABDCFE，但不包括ACBDEF

当保存到DFM文件时，该顺序将被保留：当不使用可视化继承时，组件只需按顺序保存和重新加载即可。当您使用继承时，DFM文件将被处理为派生，因此在上述情况下，当创建

TC

时，其

X

成员总是在其

Y

成员之前创建。在组件顺序很重要的情况下，需要使用

[0]

和

[1]

来通知Delphi RTL在之后修复订单

---

组件顺序的实际功能取决于组件类型。正如“前置”/“后置”名称所示，控件使用组件顺序来指定Z顺序。对于其他组件类型，它表示组件希望它表示的任何内容。例如，菜单可以使用组件顺序指定其菜单项的顺序（从上到下）。工具栏控件可以使用组件顺序指定工具栏按钮的顺序，即使这些工具栏按钮本身不是控件。数据集使用组件顺序指定字段顺序，因此也是

TDBGrid

中列的默认顺序。我最近编写了一个DFM解析器，它支持这些类型的索引。它是用Go编写的，生成的DFM文件看起来就像Delphi的

---

它是针对RAD Studio源文件和我们自己的生产代码进行测试的，它解析所有文件并逐字节生成文件。其目的是提供一种简单的方法来更改DFM树，并生成看起来像是由RAD Studio创建的输出。

创建顺序由DFM文件中的出现顺序决定，因此通过消除过程，这些必须指定我所做的z顺序，这使这个问题的问题和答案都非常清楚，它真正为hvd的答案增加的唯一一件事是，它也适用于帧和表单。我从未在DFM文件中见过这种语法，阅读问题和答案都很有趣。谢谢。我将不得不更新解析器（唉）。我确实试图从DFM中删除这些数字，但在IDE中重新加载应用程序后，它们会自动重新出现。在那之后，它们就不同了，DFM文件中组件的顺序也不同了。对于那些想做同样事情的人来说，下面是一个简短的跟进：我们放弃了Colibri解析器——太多的工作无法适应它。因为我们对对象的嵌套方式不感兴趣，所以我们只是从“object”/“Inheritated”到“end”解析ASCII文本块，处理这些块并将它们写回。@DavidHeffernan它们不一定是这个意思。它们是指成分指数。对于

TWinControl

s，它对应于Z顺序，我确实提到了“如果它们是TWinControl的后代，这意味着它们在X是显示在Y上，还是Y显示在X上有所不同。”否则，它就更复杂了。非窗口控件（例如，

TLabel

）的组件索引始终低于同一父控件中的任何窗口控件，但我不想排除在窗口子控件之上绘制非窗口子控件的父控件（这应该是可能的），对于非控件，组件索引也存在，但大部分未使用。@DavidHeffernan基本正确：DFM文件中的块是按遇到它们的顺序处理的<代码>对象和

内联