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

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

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

Я сталкиваюсь с "особенностью" в файлах DFM, которую парсер включает: [число]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
    [...]

Многие из этих DFM сильно унаследованы (мне уже пришлось адаптировать код Colibri для этого), но небольшое тестовое приложение с наследованием не смогло получить [число] в DFM.

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

Спасибо

январь

Источник

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 никогда не может быть поставлено после 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.

https://github.com/gonutz/dfm

Он был протестирован с исходными файлами RAD Studio и нашим собственным производственным кодом, и он анализирует все и генерирует файлы побайтно. Цель заключалась в том, чтобы иметь простой способ изменять деревья DFM и создавать выходные данные, которые выглядели бы так, как будто они были созданы RAD Studio.

Источник
Другие вопросы по тегам