Редактор нестандартного свойсва

← →
TStas © (2005-09-07 19:27) [0]

1) Пишу компонент, есть у него нестандартное свойство, к нему надо бы написать редактор свойства, у которого должно быть, естественно, диалоговое окно. Так это окно нужно в RunTime’е создавать полностью или можно и в DisignTime’е?
Только если можно и в DisignTime’е, тогда не пойму, как же, ведь все свойства объектов окна должны храниться в dfm’е, а где тогда должен храниться сам dfm? Смотрел диск Фаронова к книжке о компонентах, но так и не понял, где он там сами окошки редакторов свойств хранит.
В примере в книге редактор свойства ссылается на модуль с окном и все.
2) Как удалить неправильный редактор свойсва? Его же нельзя отлаживать без регистрации.

← →
Юрий Зотов © (2005-09-07 22:54) [1]

1. Раз диалог редактора нужен только в design-time, значит и жить он должен только в design-time пакете. Не и в design-time, а только в design-time, и больше нигде. Открываем этот пакет в IDE и самым обычным способом создаем в нем форму диалога. После компиляции пакета DFM будет жить в нем самом (в ресурсах BPL, то есть). Соответственно, задача редактора свойства - поднять этот диалог в методе Edit (поэтому он ссылается на его модуль).

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

← →
TStas © (2005-09-08 00:34) [2]

>Юрий Зотов
>2. Вопрос непонятен. Зачем удалять неправильный редактор? Его не удалять, его отлаживать надо.
А если сама изначальная идея редактора неверна? У Фаронова написано, что используется последний зарегистрированный редактор, то есть при отладке глючные варианты так и должны оставаться неудаленными?

← →
jack128 © (2005-09-08 00:47) [3]

TStas © (08.09.05 0:34) [2]
то есть при отладке глючные варианты так и должны оставаться неудаленными?
Какие глючные варианты?? Ты что, копируешь весь код редактора в новый пакет, исправляешь глюки и инсталируешь этот пакет в среду?? Или ты все таки меняешь код _старого_ пакета?? ;)

← →
Юрий Зотов © (2005-09-08 00:56) [4]

> TStas © (08.09.05 00:34) [2]

Правим глючный вариант и перекомпилируем пакет с редактором. До тех пор, пока не станет безглючным.

Если же редактор нужно выбросить совсем, то убираем его регистрацию (и, если надо, убираем модуль редактора из пакета и из uses других модулей).

← →
TStas © (2005-09-08 13:44) [5]

>Юрий Зотов
Я, видимо, путанно задал вопрос. Правлитьно 1-й вопрос сформулировать иначе, хотя Вы на него исчерпывающе ответили. Я имел в виду, что сама форма редактора может ведь быть и без dfm а создаваться вся в рантайме. Ведь именно так у Фаронова создается диалог пути к файлу. Тогда ведь модуль формы будет самым обычным модулем.

← →
Юрий Зотов © (2005-09-09 00:25) [6]

> TStas © (08.09.05 13:44) [5]

> Ведь именно так у Фаронова создается диалог пути к файлу.

В книге приведен пример. Но разве в ней сказано, что этот пример показывает единственно правильный способ?

Нет, не сказано. А к примеру и следует относиться как всего лишь к примеру, не более. В частности, для диалога пути к файлу я бы не создавал вообще никаких форм (потому что для этого есть TOpenDialog) - но это не значит, что их нельзя создавать вообще. Можно. Любые. Хоть кодом, хоть с DFM-ником. Кому как нравится.

>Юрий Зотов
Вот потому и спросил. То есть можно сделать полноценную форму, у которой будет переменная, а еще лучше, свойство, того же типа, что и редактируемое. Только как dfm добавлять я все равно не понял. :(

> TStas © (09.09.05 15:56) [7]
> Только как dfm добавлять я все равно не понял.

Создаете форму в пакете и компилируете его. Все добавится само.

>Юрий Зотов
То есть также, как когда модуль компонента использует другой модуль? Только что так у меня было. Там компонент использовал модуль класса, он сам добавился в пакет, только предупреждение вылезало.

Редактор нестандартного свойсва Найти похожие ветки