Вопросы по Delphi

Товарищи дельфисты, подскажите, есть ли где-то подробный разбор синтаксиса и параметров .dfm файлов?
В принципе он достаточно понятный, но там есть константы всякие, было бы лучше почитать документацию.
А может есть реализация парсера на С++? Меня интерисует только сам формат dfm, а не язык Delphi.

g-cont
> но там есть константы всякие

Так это константы самого VCL (Visual Components Library), их тыщи, смотри в документации или исходниках.

Глупый вопрос - есть ли исходники VCL и на чём он вообще написан? Меня Delphi 7 интерисует, если что.

g-cont
> Глупый вопрос - есть ли исходники VCL и на чём он вообще написан? Меня Delphi 7
> интерисует, если что.

Да, есть. Поставляется прямо с Delphi в папке Sources\VCL и написан на Delphi же.

Тут еще конечно надо понимать, что все эти TForm и TLabel и их свойства которые в .dfm написаны это не какой то "предопределённый формат", а сериализуемая часть классов VCL которые называются визуальные компоненты, причём программист волен создавать свои такие компоненты, а всё это добро описывается как раз в исходном коде на Delphi в виде программы, поэтому в целом некий универсальный парсер - вещь утопическая. Он конечно есть в исходниках там где нибудь тоже, но разобраться в нём наверное будет еще сложнее нежели просто ограничиться конкретным набором компонент и парсить по своему небольшому списочку.
Ну конечно главный вопрос - в чём цель всей затеи. От этого и надо отталкиваться.

Там есть конкретный инструментарий сериализации, но почитать надо много. Читай исходники, начни с TPersistent, TComponent, TReader, TWriter, DefineProperties. Сериализуется только то, что в published. Перечисления, простые типы, объекты (вложенные и ссылочные), коллекции, наборы.

g-cont
Сериализация происходит не для формы, а на уровне каждого компонента, и его published свойств.
Поэтому, если десериалиазция идёт не в Delphi-приложении, без наличия инфраструктуры TComponent, то и смысла смотреть исходники особо нет.

А сам формат довольно простой.

>>а сериализуемая часть классов VCL
Ага, я немного поковырял и понял это.

>>Сериализация происходит не для формы, а на уровне каждого компонента, и его published свойств.
Ну там не совсем. Там есть вложенные компоненты, дочерние классы. Т.е. чуть-чуть сложнее, чем просто дамп свойств.

>>Ну конечно главный вопрос - в чём цель всей затеи
Хочу использовать формат этих компонентов в качестве базы для своего GUI на первое время. Чтобы не пришлось мучительно гадать какому компоненту какие настройки понадобятся. А сами готовые dfm можно для тестов использовать.

g-cont
> А может есть реализация парсера на С++?
в Builder C++, очевидно.

g-cont
> Меня Delphi 7 интерисует, если что.
взял бы лазарус, там lfm есть.

=A=L=X=
> поэтому в целом некий универсальный парсер - вещь утопическая.
да-ну.. если читать их как, какой-нить json - вот и универсальный парсер.
просто какие свойства знакомы - те использовать, какие незнакомы - пропускать.
так же и с типами объектов. Известен - создаём. неизвестен - создаём заглушку. (sax parser! даже структуру держать не нужно)

Одна из удобных вещей, это, сохранение евентов. Т.е. кроме гуёвого описания, ещё есть и привязки к коду.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/main/lcl/lresources.pp
процедура парсинга LRSObjectTextToBinary.
т.к. она текст в бинарный формат перегоняет (а не в объекты через RTTI), то код может казаться неочевидным.
Но вот если посмотреть вложенную процедуру: ProcessValue,
то там можно найти все возможные встречаемые типы значений. (например строки могут быть записаны как конкатенации 'aaa'+'bbb' - чего json не смог, кроме как массивом)
чисто паскалевские вещи:
[...] - набор (set of)
(...) - список
<...> - коллекции
{hex} - бинарные данные

вся логика парсинга формата умещаетя в 300 строк. (тело процедуры LRSObjectTextToBinary, минус запись в бинарный поток) - элементращина.

ЗЫ:
я подобную задачу уже писал, но для Xcode файлов pbx.
https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/components/ip… x/pbxfile.pas
бегать и искать "а есть ли парсер pbx на паскале" не пришлось - просто написал свой с нуля.

Pbx работает аналогично dfm - такая же сериализация +- специфика Objective-C.
так вот, я отдельно собирал йерархию объектов из pbx файла, потом отдельно её перекладывал на специально заведённые классы в паскале.
Всё что было неизвестно (какие-нить свойства классов и т.п.) хранилось отдельно, но вместе с классами.

Задачи было две:

>>Одна из удобных вещей, это, сохранение евентов
Ну да, меня это в первую очередь и привлекло.

Всем спасибо за помощь, разобрался. Действительно очень простой формат, по сути каждый dfm - описание одного объекта с возможностью описания вложенных объектов. Каждый ключ - имя переменной и значение.

Чтобы не создавать новой темы, тут спрошу. Подсажите, что это вообще такое?

TRefGUID = packed record
    case Integer of
    1: (guid : PGUID);
    2: (dwFlags : DWORD);
  end;

юнион?

записи, для ленивых, кто не хочет писать ещё раз. Или пытаются объединить всё в одно.
http://www.delphi.int.ru/articles/126/

g-cont
> юнион?
Да, в корявом паскальском представлении

Mirrel
VoidSpirit
Благодарю.

Следующий вопрос. В Делфи нет ссылок, как я понял. Как он понимает какой аргумент функции надо скопировать, а на какой сослаться?
Или всё что класс - автоматически делается ссылка или там какие-то модификаторы для обратного поведения, ну например copy.
Или это вообще не контролируется пользователем?

g-cont
> Следующий вопрос. В Делфи нет ссылок, как я понял
в делфи есть ссылки.
но все объекты (инстансы классов), всегда создаются в динамической памяти, и передаются как неявные ссылки.

g-cont
> Как он понимает какой аргумент функции надо скопировать, а на какой сослаться?
у аргументов есть модификаторы:

var
const

https://wiki.freepascal.org/Var/ru

и то и другое - передача по адресу, только "var" подразумевает изменение значения.
ну и "const" не передаёт по адресу, если аргумент влезает в регистр.
если у параметра нет модификатора, то он копируется.
исключение для managed-типов