какое счастье, что я в этом не участвовал (и не буду ))

да, можно сказать нам повезло в этом смысле ) в документы мы тоже почти не лезем

кстати, тут как раз, в условиях цейтнотов, как нигде, нужны автоматизированные процессы )
потому что человек всё равно накосячит

именно! с учетом роста продуктовых серверов

добрый день гуру) столкнулся в очередной раз снеполноценностью этого мира. а точнее с ttreeview. Вопрос в следующем - требутся у каждой ноды хранить дополнительное поле. И тут есть как я понимаю два варианта: 1) Хранить указатель на структуру в node.data.  Из минусов вижу это следить за выделением памяти под структуру и самому ее очищать. Так же неудобен способ доступа к данным через типизированный указатель. 2) Писать свой класс как расширение базового класса, со своим новым свойством. Из минусов тут вижу это невоможность чтения нового свойства без приведения ноды к своему типа( что то вроде Node := TreeView1.Items.AddChild(Node, '...');
TMyTreeNode(Node).Toto := ...; ) кто что посоветует для решения поставленной задачи с максимальным удобством для обращения к новому свойству?

разные сценарии - ночной апдейт, еженедельный, срочный

сборка есть (ci), вот теперь нужна доставка (cd)

почему разные? чем срочный отличается от ночного? )

ночью можно потестировать подробнее ) тесты час идут

срочный - выборочные тесты итп

надежнее когда есть какой-то 'наружный' класс. который всё сохраняет и позже отображается в TreeView

virtualTreeView

Так это свойство и не надо отображать. Оно должно просто быть у каждой ноды. И его можно было бы считать и установить

Я как-то хранил ид элемента в ImageIndex (StaticImage)

я понимаю о чем ты. но лучше в самом тривью не хранить данных

У меня не инт. Так то я уже смотрел в эту сторону

Так хранить в отдельном списке, а там только ид

Просто это одно свойство и просто строка. Из за этого городиить целый класс

id хранить можно. только что проверять и поглядывать за ним

Хм. Чот не подумал об этом