Delphi DFM文件中的奇数[数] - 起源和必要性？ [英] Strange [number]s in Delphi DFM files - origin and necessity?

问题描述

我需要将一个包中定义的大量Delphi组件更改为另一个包中的类似的组件。
可以通过在DFM文件中替换文本（组件类型和属性）来完成大部分的工作，这些文件保存为文本。

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.

我已经搜索Stackoverflow和Google，现在正在使用来自 http：//www.felix-colibri的Felix Colibri DFM解析器.com / papers / colibri_utilities / dfm_parser / dfm_parser.html

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

我遇到了分析器所阻止的DFM文件中的功能：[number ]类型规格如下：

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

这些DFM中的许多都是很大的继承（我有为了适应Colibri的代码，已经有了），但是带有继承的小测试应用程序无法在DFM中生成[number]。

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.

我的问题在必须扩展解析器代码：有没有人知道这些[数字]来自哪里，因此，我可以在解析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?

谢谢

Jan

推荐答案

这些数字不是com完全没用假设你有课程 TA ， TB 和 TC 和 TB 和 TC 都来自 TA 。 DFM看起来像：

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 和 C 不同之处在于 X 和 Y 子组件相反。子组件顺序的精确含义取决于组件（见下文），但最显着的是，如果它们是 TWinControl 后代，或者它们都是 TControl 不从 TWinControl 派生的后代，这意味着他们是否显示 X 是否不同 Y 或 Y 超过 X 。

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:

对于正常的控件，子组件以（1） TControl 的后代开始不是从 TWinControl ，然后（2） TWinControl 后代，最后（3）任何非 TControl 组件。在每一个中，组件的相对顺序是可调整的：对于控件，前进和发送回尽可能地移动控件，限制为非 TWinControl 永远不能放在 TWinControl 之后。对于非控制，（略有错误的）创建订单选项允许您更改订单。所以，假设你有两个标签（A和B），两个编辑控件（C和D）以及一个数据集和数据源（E和F），你可以得到例如ABCDEF，BACDEF，ABDCFE ，但不是ACBDEF。

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.

保存到DFM文件时，该顺序保留：当不使用视觉继承时，组件将按顺序保存并重新加载。当您使用继承时，DFM文件将被处理为派生，因此在上述情况下，当创建 TC 时，其 X member is always 在 Y 成员之前创建。需要 [0] 和 [1] 才能告诉Delphi RTL修复订单，在那些组件顺序重要的情况。

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.

组件顺序实际上取决于组件类型。由于带到前面/发送回的名称建议，控件使用组件顺序来指定Z顺序。对于其他组件类型，它意味着组件希望它的意思。例如，菜单可以使用组件顺序来指定其菜单项的顺序（从上到下）。工具栏控件可以使用组件顺序来指定工具栏按钮的顺序，即使这些工具栏按钮本身不是控件。数据集使用组件顺序指定字段顺序，从而也可以在 TDBGrid 中的列的默认顺序。

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.

这篇关于Delphi DFM文件中的奇数[数] - 起源和必要性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！