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

nesco, я надеюсь ты это так шутишь

Dilma, а что, так нельзя разве, ну давай что-нибудь другое придумаю Например, при первом обращнии к списку, он будет создаваться, если его нет

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

Задача совершенно тривиальна: есть пользователю нужны иконки в программе - компонент должен сделать списки, не нужны - не должен. Узнать нужны они ему или нет можно в методах SetIconsState и SetIcons. Но их недостаточно, когда иконки добавляются динамически. Варианта тут два:
1) создать при первом использование
2) вывести наружу нормальное понятное каждому св-во(например UseIcons)

Впрочем есть и третий вариант: сделать элемент TreeViewIconic который по моему в данном случае устроил бы всех.

Далее при дробление элементов, о которых я уже говорил: в данном случае полной бессмыслецей является то, что в TreeView впихнуты свойства и методы по работе с ImageList, который мягко говоря отношения к элементу не имеет никакого. Это надо делать через data_element и только через него. Тоже самое касается всех менюшек и прочих элементов, работающих со списками иконок. Так что подумаем, как это нужно переделать

Наверное, это лучший вариант, а старый вернуть на место. Лучше может назвать TreeViewEx и поместить его в отведенную для этого папку

Или сделать состояние НЕ БЫТЬ для каждого св-ва любого элемента
Заодно и повыкидывать аналогичные "понятные каждому" св-ва

Где то читал что компы с тремя состояниями ячейки памяти(1,0,неопределено) являются
довольно перспективными.

А достучаться до них как можно будет

Да проще все, и понятней - должно выглядеть это для пользователя...

К примеру, на той же вкладке <Точки> есть четыре "раздельчика": Work, Event, Vars, Data
Ну появится, скажем, пятый "раздельчик" - Property
А "пцыца" там означает видимость в панели свойств
Вот и все

И, естественно, информацию об этой "пцыце" можно было бы использовать при кодогенерации...

---

Скажу сразу, на всякий случай: DTS - это другое
DTS - это когда ты хочешь, но НЕ можешь поставить "пцыцу" напротив св-ва FileName, потому-что у тебя не хватило ума сделать видимой точки doSave, или doLoad.
Или еще хитрее - подключить к ним связи (реальная логика - за автором элемента, естественно)....

Ну это -- попозже немного.

А, теперь понятно как

повторение давно завершенного диспута без привлечения новых аргументов более свойственно г-ну Tad-у, чем человеку со статусом Админ.

на SVN добавил новую версию CodeGen с элементом Project всвязи с чем просьба к разработчикам элементов свои "дуракоустойчивые" коды помещать в соответствуюшие дефайны по критериям, данным в элементе project. Тоже самое касается выдачи сообщений об ошибках через диалоговые окна. Примеры использования см. в Replace и KeyHook

интересное кино

Во-первых: убирание видимости для св-ва Icons для данного конкретного элемента смотрелось бы естественней и понятней для пользователя, чем "нормальное понятное каждому св-во(например UseIcons)". Мне именно так кажется
И таковая конкретика - является новой, мне, опять таки, именно так кажется.

Во-вторых: чтобы представлять новые аргументы, надо понимать, чего непонятно было в предыдущих.
Мне не понятно, чего было не понятно И СЕЙЧАС.
Пока мне известна только такая "контр-аргументация": НЕ НРАВИТСЯ МНЕ ЭТО
((таковая степень убедительности для Админов приемлима, видимо. И сразу как все понятно -- диспут-то завершен, оказывается))
Если кто найдет иную, не замеченную мной, аргументацию по этому адресу: http://hiasm.com/forum.html?q=3&p=74711#p74711 -- прошу показать пальцем.

В-третьих: конечно можно было бы потратить время, и пройтись ПО ВСЕМ элементам, и перечислить св-ва и элементы, где таковая "невидимость" могла бы ваглядеть естественней и понятнее, чем имеющееся сейчас
Но, честное слово, странно смотрелись бы мои указания на "понятные всем" (например) св-ва BlockFind.UserReplace или BlockFind.Delete - автору этого элемента
Или убеждать, что такового в пакете - несть числа... Кого надо в этом убеждать?
При том, что совершенно не понятна нужность таковой работы

Я вот одного не догнал, каким боком это может повлиять на создание списка иконок при помощи UseIcons, если применить этот UseIcons я могу только в Init, перед созданием контрола Тут получается, что, либо контрол будеи иметь иконки всегда (ну и дыры естественно, если не будет последних), либо если это свойство Icons окажется непустым

Это - детали. Естественно, это должно сопровождаться еще чем-то

А в кодах ты (правильнее - автор элемента) это мог БЫ получить как НЕ установку св-ва

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

------------ Дoбавленo:


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