Странно [число] s в файлах DFM Delphi - происхождение и необходимость?

Мне нужно изменить большое количество компонентов Delphi, определенных в одном пакете, на аналогичные в другом пакете. Большую часть работы grunt можно выполнить, заменив текст (типы компонентов и свойства) в файлах DFM - сохраненный как текст, конечно.

Я искал Stackoverflow и Google и теперь адаптирую парсер Felix Colibri DFM от http://www.felix-colibri.com/papers/colibri_utilities/dfm_parser/dfm_parser.html

Я сталкиваюсь с "функцией" в файлах DFM, которые парсер задыхается: [число] после спецификаций типа:

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 сильно унаследованы (мне пришлось адаптировать код Колибри для этого уже), но небольшое тестовое приложение с наследованием не смогло получить [число] в DFM.

Мой вопрос, прежде чем расширять код парсера: кто-нибудь знает, откуда взялись эти [число], и, возможно, я могу удалить их перед разбором файлов DFM?

Спасибо

Jan

Ответы

Ответ 1

Эти цифры не совсем бесполезны. Скажем, у вас есть классы TA, TB и TC, а TB и TC - оба из TA. DFM выглядят так:

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.

Удаление этих чисел может изменить формы, поэтому вы не должны слепо делать это. Однако, в зависимости от вашей цели, вы можете модифицировать синтаксический анализатор (кажется, доступен исходный код), чтобы просто пропустить цифры.

Относительный порядок компонентов обычно не имеет большого значения, но есть несколько исключений. Чтобы объяснить более подробно:

Для нормальных элементов управления подкомпоненты начинаются с (1) TControl потомков, которые не выводятся из TWinControl, тогда (2) TWinControl потомки, наконец (3) любые компоненты не TControl. В каждом из них относительный порядок компонентов регулируется: для элементов управления "Приведение вперед" и "Отправлять назад" перемещайте элемент управления, насколько это возможно, с ограничением того, что нельзя TWinControl после a TWinControl. Для неконтролируемых элементов параметр "Заказ на создание" (слегка ошибочный) позволяет вам изменить порядок. Итак, предположим, что у вас есть две метки (A и B), два элемента управления редактированием (C и D) и набор данных и источник данных (E и F), вы можете получить заказ, например, ABCDEF, BACDEF, ABDCFE, но не ACBDEF.

Этот порядок сохраняется при сохранении в файле DFM: когда визуальное наследование не используется, компоненты просто сохраняются и перезагружаются по порядку. Когда вы используете наследование, файлы DFM получают обработанную базу до производной, поэтому в приведенном выше случае, когда TC создается, член X всегда создается перед его членом Y. [0] и [1] необходимы, чтобы сообщить Delphi RTL о том, чтобы зафиксировать заказ позже, в тех случаях, когда имеет значение порядок компонентов.

Фактический порядок компонентов зависит от типа компонента. Как указывают названия "Привести вперед" / "Отправить назад", элементы управления используют порядок компонентов, чтобы указать порядок Z. Для других типов компонентов это означает, что компонент хочет, чтобы это означало. Например, меню могут использовать порядок компонентов, чтобы указать порядок их пунктов меню (сверху вниз). Элементы панели инструментов могут использовать порядок компонентов, чтобы указать порядок кнопок на панели инструментов, даже если эти кнопки панели инструментов сами не контролируют. Наборы данных используют порядок компонентов для указания порядка полей и, следовательно, также порядок столбцов по умолчанию в TDBGrid.