Form Designer without Delphi

← →
Batiskaf (2002-02-07 13:52) [0]

Привет всем. Значит хочу сначала заметить, я не большой специалист в Делфи, но что то еще помню, хотя вот уже 3 года как пишу исключительно на С++ ( и очень при этом кайфую:)))
Проблема в следующем, как известно, Делфи сериализует формы в рессурсы в формате RCDATA, что не позволяет открыть эту форму как ресурс и просмотреть ее в Вижуал Моуд( например в VC открыть как рессурсный модуль ). При рассмотрении структуры сериализации, впринципе можно понять чего он там делает, пишет имя типа, обходит поля( которые себя сами скидывают в стрим, а если они простых типов - то их форма сама в состоянии скинуть ), скидывает типы чаилд компонент и , формирует DFM файл т.д. - все что позволяется делать на динамическом связывании. Хотелось бы написать подобный вижуал едитор, только он должен работать с откомпилированными бинарными модулями ( длл и ексе ). Но проблемма как понимаю в следующем - для десериализации и построения формы и списка ее свойств мне прежде всего нужно получить доступ к типам, откомпилированным в этой длл, т.е условно говоря ф-ция GetClass("TFormFromDll") должна мне возвратить класс из этого самого модуля, но ф-ция обходит список ClassList который находится в текущем модуле и понятия не имеет что другой, подключившийся модуль имеет такой же список. Вопрос в следующем, есть ли возможность получить доступ к КлассЛист именно необходимого модуля, может есть какие то лазейки, да и Делфи же в состоянии как то визуализировать DFM модуль, хотя может он компилирует находу... Кароче, если кто копался в этой теме - поделитесь, буду очень благодарен.

← →
Batiskaf (2002-02-07 15:42) [1]

Ну кто нибудь скажет мне чего нибудь вразумительное по-этому поводу???

← →
Johnmen (2002-02-07 15:46) [2]

Это вряд ли - никому не интересно...:(

← →
Batiskaf (2002-02-07 16:09) [3]

Удалено модератором

← →
Johnmen (2002-02-07 16:15) [4]

Кто-нибудь знает ;) , да только ему не интересно тереть на эту тему....лень....

← →
vuk (2002-02-07 16:37) [5]

Никаких внутренних списков классов для модуля в RTTI нет.

← →
Batiskaf (2002-02-07 17:09) [6]

Уважаемый vuk, рекомендую вам прежде чем чего-то говорить, покопаться в исходниках VCL и выяснить чего же делает ф-ция GetClass и какой список она обходит

← →
vuk (2002-02-07 17:29) [7]

to Batiskaf:
Вы думаете я не знаю что делает GetClass? Не волнуйтесь, я это знаю, а вот Вы похоже нет. :o) GetClass обходит список классов, зарегистрированных при помощи RegisterClass. А это используется крайне редко (на всю VCL D5 всего 3 случая использования). Как Вы думаете, вернет Вам GetClass что-нибудь полезное? ;o)

← →
EAlexander (2002-02-07 17:29) [8]

Form Designer в Delphi - это вообще отдельная песня, причем он даже навороченный и много чего может, что обычно не используется.

И что мешает, просто прочитать RCData, после чего перевести все это в TXT и интерпритировать себе на здоровье.

P.S. в для КАЖДОГО компонента (и не визуального тоже) Delphi хранит координаты, где его поместить на Form (или Parent), после чего за отрисовку компонента уже отвечает package, который содержит этот компонент и в design-mode работает только пакет.

P.S. в Design mode через Designer можно обратиться к реальной форме, ту, которую мы видим на экране и обходить ее как обычную форму.

← →
Юрий Зотов (2002-02-07 19:27) [9]

> Как получить КлассЛист другого модуля...

Никак. Список классов для МОДУЛЕЙ не строится, он ОДИН на всю программу. Но для run-time он сам собой не формируется, это надо делать ручками. А Вы, похоже, этого не делаете, поэтому GetClass Вам ничего и не дает - а вовсе не потому, что она ходит по какому-то там несуществующему "списку другого модуля".

> ...кто специалист в структуре RTTI в Делфи???

Например, Vuk. Или я. Или еще очень многие. Но, как Вам уже сказали, список классов к RTTI прямого отношения не имеет.

> ...рекомендую вам прежде чем чего-то говорить, покопаться в исходниках VCL...

Вот в этом я Вами полностью согласен.

← →
dimich (2002-02-08 08:43) [10]

Молодцы !!! Наругались в сласть!!!

← →
Johnmen (2002-02-08 09:47) [11]

А я с самого начала сказал, что с этим челом нечего тереть !

← →
Алексей Петров (2002-02-08 10:09) [12]

Список классов можно и без RegisterClass получить, но хаккерскими методами. Причем код получится разным в зависимости от версии Delphi, которой собран exe-шник.

Все VMT со всем сопутствующим хламом лежат в памяти одна за другой. Находите первый из них и вперед. Если Package-ей нет, то первым будет TObject.

Если packages есть - еще проще. Каждый Package экспортирует имя класса с небольшой декорацией и адресом VMT в виде точки входа.

← →
Batiskaf (2002-02-08 14:59) [13]

To All: Ну и добряки же вы однако :))) Мне всегда казалось что такие фундаментальные вещи разобрать да и другим донести всегда гораздо интереснее нежели копаться с кнопочками и формочками. Ну да ладно, хозяин барин как говорится.

To Алексей Петров.
Большое спасибо Вам за Ваше участие, если можно по-подробнее о экспортируемых Package и именах с декорацией. Три строки кода для наглядности тоже не помешают, заранее благодарен.

← →
Алексей Петров (2002-02-08 16:02) [14]

> Batiskaf (08.02.02 14:59)
На счет 3-х строк кода - о чем речь?
Если хотите подробнее - откройте любой package утилитой, показывающей структуру PE файла - и смотрите. Все там видно.
А описывать это - слишком объемно.

← →
Vuk (2002-02-08 16:05) [15]

to Bstiskaf:
Даже если Вы получите список классов, что Вы будете с ним делать?
Если вы хотите создавать приложения с настраиваемым интерфейсом, то не кажется ли Вам, что вы немного не с той стороны заходите?
Не проще ли будет вынуть ресурс, построить по нему текстовое описание, а потом уже по нему - внешний вид фомы. Все нестандартное можно в конце концов просто рамочками с надписью заменить...

Но лучше будет, если есть такая возможность, встроить поддержку настраиваемого интерфейса в исходное приложение.

← →
Юрий Зотов (2002-02-08 16:26) [16]

> Но лучше будет, если есть такая возможность, встроить
> поддержку настраиваемого интерфейса в исходное приложение.

Если мы хотим создать Delphi-образный редактор, то, похоже, другой возможности просто и нет. Поскольку, например, TObject в двух разных программах - это два разных класса. Значит, даже если удастся получить список классов из EXE или DLL, он окажется практически бесполезным - мы получим имена классов, но не сами классы.

Либо надо идти путем Алексея Петрова - грузить этот EXE/DLL к себе, искать в нем все VMT и строить список классовых ссылок ручками. Но тогда, как сам Алексей и заметил, редактор будет привязан к версии Delphi, в которой компилировался этот EXE/DLL - значит, надо найти еще и способ отвязки. Наверняка возникнут и другие проблемы.

В то время как тот же редактор, но встроенный в саму программу, пишется почти легко и даже почти просто.

← →
Batiskaf (2002-02-08 19:41) [17]

to Юрий Зотов.
{ Если мы хотим создать Delphi-образный редактор, то, похоже, другой возможности просто и нет. Поскольку, например, TObject в двух разных программах - это два разных класса. Значит, даже если удастся получить список классов из EXE или DLL, он окажется практически бесполезным - мы получим имена классов, но не сами классы. }
Если вы имеете в виду что у процессов разделяемые адресные пространства, то это я вас уверяю не большая проблема - при помощи CreateRemoteThread я могу построить поток в другом процессе из своего процесса, как процедуру окна я даю адресс ф-ции LoadLibrary( ее прототип вполне подходит для процедуры потока: DWORD WINAPI ThreadFunc( LPVOID ) и HINSTANCE LoadLibrary (LPCTSTR lpLibFileName )), а параметром для нее я передаю имя своей длл - и вот я уже в данном процессе, в DllMain отстреливаю новый поток и как рыбка в воде. Единственная проблема(точнее две) - передав в CreateRemoteThread адрес ф-ции LoadLibrary мы передаем адрес ф-ции из нашего процеса в другой, а там такого адреса может и не быть. Единственное радует что это ф-ция системной библиотеки, так что Маунт Поинт системных длл-ей в двух процессах одинков а RVA експортируемой ф-ции соответственно тоже. По-этому стоит передавать в CreateRemoteThread не ф-цию-шлюз а истинную ф-цию LoadLibrary ( по-средством GetProcAddress ). И проблемма с параметром ф-ции нового потока - имя длл-ки нужно алоцировать тоже в адресном пространстве того процесса ( VirtualAllocEx).

С подгрузкой длл-к же таких вышеописанных проблем нет - адрессное пространство длл-и полностью принадлежит мне( точнее процессу моего "абстрактного" Форм Дизайнера).

Вопрос в другом - допустим что у меня в исследуемой Делфи длл определен класс TMyHrenZnamoForm ( имя этого класса я из рессурсов поднять могу - ObjectBinaryToText). И вот из своего процесса я хачу получить класс TClass этого типа. Насколько я почитал, VMT лежит в первом поле со смещением 4 байта от моего инстанса - но инстанса то у меня нет!!! Или может я чаво не понял - другими словами, как из имени класса получить его инстанс, причем класс определен в подключаемом модуле. Ведь для языков с динамическим связыванием это должно делаться как два байта переслать. Прашу прощения за столь прозрачные изречения - напрочь забыл Делфю, помнится все в общих чертах, но вы пишите код, пишите - я пойму :))

to Алексей Петров:
Насколько я помню, Борланд не придерживается Микрософтовского формата PE - они используют Intel OMF? А DumpBin кажется работает только с PE и COFF.

← →
Vuk (2002-02-08 22:00) [18]

>Или может я чаво не понял - другими словами, как из имени
>класса получить его инстанс, причем класс определен в
>подключаемом модуле.
В общем случае - никак. Хотя из пакета если его динамически подгрузить, может и можно что вытянуть. Для этого придется разбираться как компилятор преобразует имена символов и что именно за что отвечает.

>Насколько я помню, Борланд не придерживается Микрософтовского
>формата PE - они используют Intel OMF
Вы формат исполняемых модулей с форматом объектных модулей не путаете? ;o)

Не ломайте Вы себе голову, все равно на форму добавить что-то, что туда не положили во время разработки не получится, можно только имеющееся подвигать, ну может еще свойствами пощелкать. А такие вещи проще из самой программы делать, а не из внешнего редактора.

← →
Дремучий (2002-02-08 22:52) [19]

Vuk ©
{ Не ломайте Вы себе голову, все равно на форму добавить что-то, что туда не положили во время разработки не получится, можно только имеющееся подвигать, ну может еще свойствами пощелкать. А такие вещи проще из самой программы делать, а не из внешнего редактора. }
а редактор 1с кажется умеет все (с определенным набором класов)...
;)

Form Designer without Delphi Найти похожие ветки