Для чего мне это нужно.

Есть компонент, одно из свойств которого - TCollection. Есть необходимость обращаться к конкретным элементам коллекции. Я даже сделал свойство Name для TCollectionItem и поиск по имени у TCollection.

Мне хочется, чтобы все TCollectionItem-ы содержались в классе формы, аналогия с TMenuItem.

1. Сделать некомпонентский класс компонентским невозможно.

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

3. Если нужно, чтобы элементы коллекции сохранялись в DFM, сделайте коллекцию в компоненте published свойством.

> Юрий Зотов ©   (13.01.08 21:49) [1]

Представьте...
Есть форма, у которой есть свойство
(TCollectoin). В редакторе свойств я добавляю элемент, элементу автоматически присваивается имя (
) "Item1", а в
появляется поле


Как этого добиться?

Никак. Для того, чтобы элемент коллекции появлялся и исчезал, как поле формы (аналоги - TMenuItem, TField...), он должен быть компонентом. А компонентом он быть не может. И от добавления ему свойства Name ничего не изменится.

И незачем это. Потому что элементы коллекции среде и так доступны - через владельца коллекции (которым, кстати, может быть и сама форма).

> Юрий Зотов ©   (13.01.08 23:08) [3]

Я прекрасно понимаю, что TCollectionItem не может стать TComponent-ом по определению. Я прошу посоветовать, как мне наилучшим образом справиться с проблемой.

Нет ли какого-нибудь аналогичного класса, имеющего похожий редактор, но работа велась бы с TComponent-ами ?

Или может быть как то через кодо-генереторы ? О_о?

Может Delphi позволяет как-то изменять/добавлять строки в published-секции ?

> DevilDevil   (13.01.08 23:19) [4]

Чтобы посоветовать, как наилучшим образом справиться с проблемой, нужно понимать саму проблему. Пока я ее не только не понимаю, но и вообще никакой проблемы не вижу (вернее, вижу проблему надуманную, а такие проблемы всерьез не рассматриваю).

Элементы коллекции создаются и уничтожаются, они доступны и среде, и коду, все нормально работает - и нет практически никакой разницы, как писать:

1. Как сейчас:



2. Как будет, если владельцем коллекции сделать саму форму:



3. Так, как Вы хотите, но непонятно, зачем:

Сорри, забыл тег закрыть после


> DevilDevil   (14.01.08 00:03) [5]

> Может Delphi позволяет как-то изменять/добавлять строки
> в published-секции ?

Она сама это делает, когда на форме повляется компонент (или удаляется, или переименовывается). Причем без разницы, положили этот компонент туда руками (из палитры), или его создала среда (редактор пунктов меню, редактор полей и т.п.). Но это должен быть именно компонент, с элементом коллекции такое не прокатит.

> Юрий Зотов ©   (14.01.08 01:16) [7]

Да, задача у меня нестандартная, поэтому и понять "зачем" сложно.

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

Почему тогда коллекция, а не просто компонентов накидать?
Причин несколько:
- коллекция позволяет визуально компактно расположить элементы, а куча компонентов (около 15) визуально будет мешать
- коллекция позволяет задать порядок (что в моём случае крайне важно)
- в редакторе коллекции имеется возможность добавлять описание, что очень даже полезная фича

Мне кажется вам коллекция не нужна. Посмотрите на TActionList

> DimaBr ©   (14.01.08 09:12) [9]

Посмотрел...
Да, немного похоже, только намного сложнее, чем мне надо.
Может ещё какие варианты?

> DevilDevil ©   (14.01.08 11:01) [10]

Варианты чего? Что нужно-то?

Обращение к элементу по имени? Так уже было сказано, как это сделать.

Еще что-то? Тогда что?

Ничего сложного нет
Вот ваши требования

> - коллекция позволяет визуально компактно расположить элементы, а куча компонентов (около 15) визуально будет мешать
> - коллекция позволяет задать порядок (что в моём случае крайне важно)
> - в редакторе коллекции имеется возможность добавлять описание,  что очень даже полезная фича

1. Не коллекция а редактор коллекции
2. Порядок = порядку считывания из ресурса
3. Не понял вообще

> [8] >а куча компонентов (около 15) визуально будет мешать
компоненты TMenuItem и TField - на форме не видны

потерял я веру. Может быть существует какой-нибудь TComponentCollection ? Всё, что я нашёл либо не работает либо не имеет хорошего редактора.
Ну или хитрым образом как-то можно модернизировать TCollection?

> компоненты TMenuItem и TField - на форме не видны
в том то и задача, чтобы было 15 компонентов, порядок их можно задавать произвольный, а редактировать в DesignTime посредством редактора аналогичного редактору TCollection.

> 3. Не понял вообще
TCollection позволяет делать такое:
http://devilhome.narod.ru/description.png  
(пользуясь случаем, Юрий, спасибо за статью)

Я нарисовал такой компонент (точнее похожий) - контейнер для хранения множества компонентов
http://dymondbox.narod.ru/1.JPG

Решение очень простое
Вы уже написали компонент с коллекцией обьектов, следовательно остаётся нарисовать редактор этой коллекции который:
1. при выборе элемента коллекции выбирал Object на форме и соответственно в инспекторе
2. в дополнительном окне  (в редакторе) отображал свойства и значения самого элемента коллекции.

В принципе готовый редактор есть в сырцах делфи остаётся его немного видоизменить и вызвать для  своей коллекции.

Дополнительное окно даже не нужно. И коллекция тоже не нужна. Все делается по аналогии с полями.

Целевые компоненты делаются невидимыми (аналоги полей). Пишется компонент-контейнер таких невидимых компонентов. (аналог TDataSet). К нему пишется редактор (аналог редактора полей). В редакторе (и в дизайнере формы) выбирается невидимый компонент, который отображается в самом инспекторе.

> DimaBr ©   (17.01.08 11:41) [16]
> Юрий Зотов ©   (17.01.08 18:36) [17]

Если честно, относительно сложно для понимания... но я стараюсь :)

>  Пишется компонент-контейнер таких невидимых компонентов.
>  (аналог TDataSet). К нему пишется редактор (аналог редактора
> полей). В редакторе (и в дизайнере формы) выбирается невидимый
> компонент, который отображается в самом инспекторе.

Опишите, пожалуйста, по подробнее. Почти ни слова не понимаю.

Моя проблема в принципе решается, если вручную делать примерно так:



Ну и потом, в
, имея
элемента коллекции, присваивать published-полям соответствующие значения.

Вопрос: возможно ли написать кодогенератор, который автоматически редактировал бы мою published-секцию ?

> Целевые компоненты делаются невидимыми (аналоги полей).

?
что означает "сделать невидимыми" ?

>  Пишется компонент-контейнер таких невидимых компонентов.

?

>  К нему пишется редактор
редакторы не писал ни разу. Я могу в качестве основы взять редактор для TCollection ?

Давайте сначала !!!
У вас есть перечень компонентов на форме которыми вы хотите управлять из некоего редактора аля TCollectionEditor
Или у вас есть перечень компонентов внутри некоего компонента которые "не видны" (создаются внутри компонента) на форме и которыми вы хотите управлять.

> DimaBr ©   (18.01.08 08:44) [21]
у меня есть  класс формы (допустим
), у которого есть свойство
. Я сделал так, чтобы элементы однозначно идентифицировались по свойству
, например, так:



Мне желательно, чтобы
содержал в себе соответствующие
-поля и создавались они автоматически.

Впринципе проблема решается ([19]), но делается это добавлением полей вручную и:

Ничего не понял.
Имеется форма, у которой нужно организовать доступ по имени объекта ?
Так FindComponent поможет.

Чесно говоря я вообще не понимаю смысл вашей затеи. Опишите пожалуйста что вы хотите иметь в конечном результате желательно с примерами (без кода)

Насколько я понял, он хочет, чтобы:

- каждый элемент коллекции имел имя;
- форма имела поле с тем же именем;
- это поле указывало на компонент.

Это-то мне и непонятно, зачем "масло-масленное".
Форма уже имеет поименованную "коллекцию" элементов

> Юрий Зотов ©   (18.01.08 15:06) [24]

:) всё верно.

> Форма уже имеет поименованную "коллекцию" элементов
эээ...
именована сама коллекция, а не элементы.
а зачем и почему... потому что
лучше, чем

> DevilDevil ©   (18.01.08 17:59) [26]

Все это действительно делается по аналогии с полями, но за это Ваше "лучше" придется заплатить довольно дорого. В частности, придется написать классы невидимых компонентов и их контейнера (а в них - код для правильного сохранения невидимых компонентов в DFM и их последующей загрузки), процедуру регистрации невидимых компонентов (аналог RegisterField) и механизм поддержки этой процедуры (внутренний список IDE), редактор (аналог редактора полей)... ну и еще что-то, возможно.

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

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

> Юрий Зотов ©   (18.01.08 18:41) [27]
> Стоит ли овчинка выделки?

Вопрос в цель. Спасибо, Юрий, что разъяснили.
Решил обходиться ручным вписыванием полей в published секцию.

Огромное спасибо всем, что потратили уйму времени на помощь!