Y
в любой другой ситуации я бы тоже сказал "используй стандартный средства", но не в ситуации с VirtualTree
Я уже давно отказался от стандартного TreeView. :) TvirtualStringTree для меня must have.
Size: a a a
2020 February 27
a
YuS
Я уже давно отказался от стандартного TreeView. :) TvirtualStringTree для меня must have.
VirtualStringTree вроде как стандартный в лазарусе? А для делфи да, надо ставить, справка причём более чем полная (не сарказм). Поравьте плз, если не прав
Y
VirtualStringTree вроде как стандартный в лазарусе? А для делфи да, надо ставить, справка причём более чем полная (не сарказм). Поравьте плз, если не прав
Нет, в стандартную поставку Lazarus не входит. Я из менеджера пакетов устанавливаю.
SB
добрый день гуру) столкнулся в очередной раз снеполноценностью этого мира. а точнее с ttreeview. Вопрос в следующем - требутся у каждой ноды хранить дополнительное поле. И тут есть как я понимаю два варианта: 1) Хранить указатель на структуру в node.data. Из минусов вижу это следить за выделением памяти под структуру и самому ее очищать. Так же неудобен способ доступа к данным через типизированный указатель. 2) Писать свой класс как расширение базового класса, со своим новым свойством. Из минусов тут вижу это невоможность чтения нового свойства без приведения ноды к своему типа( что то вроде Node := TreeView1.Items.AddChild(Node, '...');
TMyTreeNode(Node).Toto := ...; ) кто что посоветует для решения поставленной задачи с максимальным удобством для обращения к новому свойству?
TMyTreeNode(Node).Toto := ...; ) кто что посоветует для решения поставленной задачи с максимальным удобством для обращения к новому свойству?
Настоятельно рекомендую VirtualTreeView, оно умеет и деревья хорошо показывать, и таблицы. Один из лучших бесплатных компонентов. В нем у каждого узла есть поле Data неопределенного типа, в котором можно хранить любые данные. Рекомендую там хранить индекс в списке объектов данных.
AS
я пока придумал только доп свойство для ветки (в данном случае string) чтобы различать ветки и по case вызывать тот или иной код. поему не стал по индексу? ветки формируются динамически и индексы могут отличаться
чтобы различать ветки и по case вызывать тот или иной код.
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
R
чтобы различать ветки и по case вызывать тот или иной код.
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
согласен. но как есть пока. в будущем перепилю может.. а пока надо заставить работать хотя бы на костылях
SB
VirtualStringTree вроде как стандартный в лазарусе? А для делфи да, надо ставить, справка причём более чем полная (не сарказм). Поравьте плз, если не прав
К сожалению, не входит в число стандартных компонентов LCL, но входит в состав дополнительных пакетов IDE.
R
чтобы различать ветки и по case вызывать тот или иной код.
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
херовое неудачное решение. как по мне...
когда ты добавишь новое действие, тебе придётся менять код, который уже работал - добавлять новую ветку в case
изменение уже существующего кода - это потенциальная возможность совершить ошибку )
меня от такого ломает )))
и не надо мне рассказывать "да чо там, там всё просто"... проходили...
а как лучше тогда сделать?
AS
я хотел от этого отказаться в силу того чтобы не запоминать индексы. а вместо них ввести читабельную строку по которой я сразу пойму что за действие требуется
я бы делал так:
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
R
я бы делал так:
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
типа указатель на обьект класса у которого есть метод для выполнения нужного дествия?
R
хм.. не плохо.. в обработчике кнопки только извлечь обьект и вызвать метод.. хмм. довольно гибко
Y
типа указатель на обьект класса у которого есть метод для выполнения нужного дествия?
Именно.. а в Data который Pointer хранить указатель.
AS
типа указатель на обьект класса у которого есть метод для выполнения нужного дествия?
да, именно
причём это "действие" называется .Execute/.Run/.Do , etc...
есть базовый (абстрактный класс) , а каждое конкрентное действие - оверрайдит и реализует его...
причём это "действие" называется .Execute/.Run/.Do , etc...
есть базовый (абстрактный класс) , а каждое конкрентное действие - оверрайдит и реализует его...
R
да, именно
причём это "действие" называется .Execute/.Run/.Do , etc...
есть базовый (абстрактный класс) , а каждое конкрентное действие - оверрайдит и реализует его...
причём это "действие" называется .Execute/.Run/.Do , etc...
есть базовый (абстрактный класс) , а каждое конкрентное действие - оверрайдит и реализует его...
ну да.. все классы наследуют его и имеют один и тот же метод
AS
👌
читайте умные книжки ))
читайте умные книжки ))
R
спасибо)
DB
ну тут можно пробовать. только что за актуальностью указателей поглядывать
R
а что если хранить указатель на функцию класса. если один класс реализует несколько методов для разных действий?
SB
я бы делал так:
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
при заполнении дерева, сразу назначал в data объект, получая доступ к которому, ты сразу выполняешь то действие, которое он "символизирует" (паттерн "команда", по-моему)...
да, это не настолько "быстро" как многие тут хотят... но это поддерживаемое и расширяемое решение...
Пихать в Data указатель на объект - очень плохое и опасное решение. Можно запросто словить обращение к уничтоженому объекту. Лучше пихать туда индекс списка, его легко проверить.
AS
спасибо)
