VMT и TPropertyEditor.

← →
Palladin (2003-05-12 15:10) [0]

Каким же образом манипулировать TPropertyEditor и VMT, что бы Object Inspector видел методы форм-предков?

Уважаемому Юрию Зотову.
Ну чтож, конечно же я не справился с Вашей задачей за две недели, (+1 день :) ). Признаю это без всякого огорчения, потому что в процессе копания не мало узнал интересных вещей и хоть как то размял мозги от рутины. За что Вам и спасибо.
Впредь постараюсь давать более подробные ответы-советы, если конечно вопросы этого заслуживают.

И все же вопрос мне жутко интересен.

← →
vuk (2003-05-12 15:29) [1]

Если Вы о необходимости видеть published свойства форм-предков, то там не VMT надо манипулировать, а CustomModule строить.

← →
Palladin (2003-05-12 15:47) [2]

нет
задача стояла в другом

существует иерархия форм, чистое описание, только описание, необходимо сделать видимыми published методы форм предков для Object Inspector

← →
Skier (2003-05-12 15:56) [3]

>Palladin
А зачем это ?
свойства и события в ИО это я понимаю, а вот зачем там методы ?
Или это из "спортивного" интереса ?

← →
vuk (2003-05-12 15:59) [4]

Это... Я, может, чего не понял? Bх и так видно.

← →
vuk (2003-05-12 16:01) [5]

Правим опечатки:

>Bх и так видно.
Их и так видно.

← →
Palladin (2003-05-12 16:03) [6]

нет

← →
Mike_Goblin (2003-05-12 16:08) [7]

Как Вам уже сказали _методы_ в Object Inspector - это очень оригинально (как вы их настраивать собираетесь)
а вот published свойства по умолчанию действительно не видны
читайте доку про RegisterCustomModule и будет Вам счастье

← →
vuk (2003-05-12 16:09) [8]

Delphi6:
Создаю форму, кидаю кнопку Button1, создаю два метода:

procedure Click1(Sender:TObject);
procedure Click2(Sender:TObject);

Делаю наследника формы. В ObjectInspector в списке обработчиков для Button1.OnClick вижу Click1, Click2.

Или Вы имеете ввиду что-то другое?

← →
Юрий Зотов (2003-05-12 17:44) [9]

Должен внести ясность. Задача ставилась так.

Есть иерархия форм. Только PAS, никаких DFM и никаких компонентов. Сами классы форм, их объявление и реализация - больше ничего. То есть, как у TCustomForm.

В этих классах объявлены (в секциях published) и реализованы какие-то методы, по структуре объявлений точно соответствующие каким-то типам обработчиков событий.

Теперь я порождаю рабочую форму с DFM, как потомка одной из этих форм. Естественно, она наследует упомянутые методы и видит их. Кладу на эту форму нужные компоненты и хочу через Object Inspector назначить их событиям эти самые унаследованные обработчики. Но в выпадающем списке их нет. По крайней мере, в D5.

А надо, чтобы были. Причем ВСЕ унаследованные, а не только от ближайшего предка. Но при этом чтобы не все подряд, а только те, которые соответствуют типу данного события. То есть, чтобы всё было, так, как будто эти методы прописаны в самой форме, а не в ее предках.

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

"VMT + TPropertyEditor".

И сказал, что этого ответа, в принципе, достаточно, но он настолько краток, что с этой задачей запросто можно промучиться месяц-другой. Поэтому такой ответ практически ничего не дает спрашивающему, кроме как указывает общее направление, в котором ему долго и упорно придется копать.

Вот. Вроде бы, ничего не исказил (а если исказил, прошу поправить).

← →
MalkoLinge (2003-05-12 17:51) [10]

А я бы в силу своей неопытности формировал бы список (в редакторе компонента) опубликованных методов. Для этого есть замечательная технология RTTI. И намного проще на первый взгляд.

← →
vuk (2003-05-12 18:01) [11]

to Юрий Зотов:
>Есть иерархия форм. Только PAS, никаких DFM и никаких
>компонентов. Сами классы форм, их объявление и реализация -
>больше ничего.
Ну тогда всё равно без CustomModule не обойтись.

>в выпадающем списке их нет. По крайней мере, в D5.
В D6 видны методы не только непосредственного предка.

← →
vuk (2003-05-12 18:07) [12]

to MalkoLinge:
>А я бы в силу своей неопытности формировал бы список (в
>редакторе компонента) опубликованных методов.
И что Вы надеетесь таким образом получить? Ведь в режиме дизайна контейнером является не Ваш класс, а специальная форма-контейнер. А у нее в published совсем не то, что написано у Вас в исходном коде.

← →
Skier (2003-05-12 18:09) [13]

>vuk © (12.05.03 18:07)
форма-контейнер в дизайне является не контейнером, а владельцем.
Разница ! :)

← →
Юрий Зотов (2003-05-12 18:12) [14]

> MalkoLinge © (12.05.03 17:51)

Редактор - это да, только не компонента, а свойста (поэтому и было написано - TPropertyEditor). Но через RTTI Вы не получите список методов, его можно получить проходом по Method Table(поэтому и было написано - VMT). Хотя, строго говоря, это тоже часть RTTI, но не то, что обычно имеют в виду под этим словом.

И возникнет еще одна проблема - ведь этот редактор надо будет зарегистрировать для ЛЮБОГО события, независимо от компонента, которому оно принадлежит, а также независимо от названия и типа этого события. Первое и второе делается элементарно, а вот третье... тоже, в общем-то, пишется в пару строк, но, пока эту пару строк родишь, голову поломать придется изрядно, и полазить по исходникам VCL - тоже.

← →
Юрий Зотов (2003-05-12 18:24) [15]

> vuk © (12.05.03 18:01)
> Ну тогда всё равно без CustomModule не обойтись.

Я обошелся. Задача не высосана из пальца, такая действительно стояла и была решена на практике. Помните, я как-то говорил о том, что писал свою IDE? Вот там она и решалась.

А с CustomModule есть одна проблема. В нем все понятно, кроме одного - как правильно писать CreateDesignerForm (а вот он-то здесь и потребуется, если идти через CustomModule). Несколько месяцев назад мне пришлось повоевать с этой штукой, искал хотя бы один пример - так ничего и не нашел. И никакой документации тоже. Борландовая конференция по OTAPI тоже не помогла. В итоге написал по интуиции, но работало кривовато. Явно написал не то.

← →
vuk (2003-05-12 18:43) [16]

to Skier:
>Разница ! :)
Разницы нет. Владелец или контейнер - какая разница как называть? А результат один, и он таков, что то, что написано в исходнике, в режиме дизайна, не существует в виде исполняемого кода, и, следовательно RTTI для него отсутствует. Дизайнер же это всё получает исключительно путём парсинга исходников, а никак не через RTTI.

to Юрий Зотов:
>Я обошелся.
В своей IDE может и можно, но с IDE Delphi проблема, на мой взгляд, изложена выше. Или я где-то не прав?

А если насчет реализации CustomContainer, то насколько я знаю, в QuickReport такой подход используется. Осталось исходники посмотреть. :o)

← →
Palladin (2003-05-12 19:51) [17]

в том то и проблема, что ясен пень, задача из пальца не высосана, это видно по тексту задачи, и это интересно
но я не смог (или можно сказать не успел, но это отмазки, раз обещал, значит обещал, или провалился)

← →
Юрий Зотов (2003-05-12 20:56) [18]

> Palladin © (12.05.03 19:51)

Провалиться здесь не мудрено, задачка эта совсем не тривиальная, а для тех, кто раньше не имел дела с IDE - откровенно сложная (да и для тех, кто имел - тоже не слишком-то простая). А Вы еще и сами себе сократили срок до пары недель. Поверьте, я не зря писал - пара месяцев (и это еще при условии, что эти пару месяцев придется пахать часов по 15 в сутки). Правда, тогда я решил ее быстро, буквально за полдня, но это вовсе не показатель, потому что я был ГОТОВ к этому, а вот на эту ГОТОВНОСТЬ ушло несколько лет. Вот почему я и говорил - такой подсказки, в принципе, достаточно, но далеко не каждому, потому что в этом деле много специфики.

Если в ближайшее время отпустят в отпуск, то попробую воссстановить свой код (правда, придется по памяти, исходников нет, но идеи, вроде бы, не забыл), нарисую что-то типа редактора или эксперта IDE и выложу.

← →
vuk (2003-05-12 21:30) [19]

to Юрий Зотов:
Если не сложно, хотя бы намекните на то, как это было реализовано. А то я что-то не вижу реальной возможности выполнения вот этого:

>Теперь я порождаю рабочую форму с DFM, как потомка одной из этих
>форм.

кроме как через CustomContainer...

← →
Юрий Зотов (2003-05-12 22:09) [20]

> vuk © (12.05.03 21:30)

Какой тут нужен PropertyEditor, как высосать названия методов из Method Definition Table (рекурсивно по всем предкам) и как загнать эти названия в список - это думаю, для нас обоих не проблема. Тогда остаются, собственно говоря, 2 вопроса:
- фильтрация списка в GetValues по типу события;
- регистрация одного редактора для всех типов событий разом (поскольку nil вместо TypeInfo не напишешь).

Первый вопрос можно решить через RTTI - получаем список параметров для данного типа события и парсим объявление класса на соответствие параметров. Второй - надо покопаться в VCL, там есть что-то типа MapPropertyEditor - через эту штуку предыдущий TMethodProperty подменяется своим. Естественно, надо предусмотреть корректное восстановление при выгрузке пакета.

Что-то в этом роде, насколько я помню (все-таки уже года три прошло).

← →
Юрий Зотов (2003-05-12 22:15) [21]

> vuk © (12.05.03 21:30)

Елы-палы, ответил совсем не на тот вопрос... плохой стал...

Да какая разница, хоть через CCPack, хоть через свой, упрощенный. В принципе, никто не мешает и просто ручками изменить предка, а потом переоткрыть проект.

← →
vuk (2003-05-12 22:17) [22]

PropertyEditor - не проблема. Вот вытягивание из MDT - проблема, т.к. в дизайне у нас контейнер, мягко говоря, не тот (я это уже 3-й раз повторяю) и вытянется оттуда не то. А если тот, то это CustomContainer. Другого метода заставить дизайнер использовать в качестве контейнера что-то нестандартное я не вижу. Или я опять чего не понимаю...

← →
vuk (2003-05-12 22:19) [23]

to Юрий Зотов:
>В принципе, никто не мешает и просто ручками изменить предка, а
>потом переоткрыть проект.
Дык ни предок ни наша форма от этого в виде двоичного кода внутри IDE сами собой не образуются...

← →
Юрий Зотов (2003-05-12 22:32) [24]

Дык... елы палы.. а как Delphi-то сама делает? У нее же формы-предки (TCustomForm и TForm) в пакете сидят - отсюда и код берется. И здесь надо делать так же - загнать иерархию в пакет, а от него уже наследоваться. И все прокатывает.

← →
vuk (2003-05-12 22:39) [25]

Ну раз в пакет, тогда да. Только IMHO без регистрации там контейнер всё равно стандартный будет получаться. Не уверен, надо будет проверить...

По поводу подмены Property Editor.
Из DesignIntf.pas (D6):

type
TPropertyMapperFunc = function(Obj: TPersistent;
PropInfo: PPropInfo): TPropertyEditorClass;
TRegisterPropertyMapperProc = procedure (Mapper: TPropertyMapperFunc);

var
RegisterPropertyMapperProc: TRegisterPropertyMapperProc;

procedure RegisterPropertyMapper(Mapper: TPropertyMapperFunc);

← →
Юрий Зотов (2003-05-12 23:17) [26]

Во-во, об этом и говорилось. Я тогда эту штуку, наверное, целый час искал. Помнил, что видел, а где и как называется - напрочь забыл... В такой ситуации Search - как мертвому припарки, вот и копал ToolsAPI ручками.

VMT и TPropertyEditor. Найти похожие ветки