САПР на Lazarus

[Sharfik]

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

[zub]

"Я удалился", "Я изменился" - потребуют поиска себя в дереве. если из 5000 устройств разом изменится 500 - этот поиск съест весь выигрыш и превратит его в проигрыш.
Или придется хранить в примитивах их ноды в навигаторах. Что тоже непросто. примитив ниче о навигаторах не знает и знать недолжен

[serbod]

10К узлов это не так уж и много. Я использую TVirtualStringTree, где принудительно обновляется только список узлов, а видимые данные (названия, иконки, цвета) определяются только при отрисовке, через OnGetText, OnGetImageIndex, OnGetHint, OnBeforeCellPaint и т.д, где из поля Data узла получаем его объект. Для обновления визуального дерева достаточно сделать Invalidate()

Заполнение 15К узлов занимает мелкую долю секунды и выполняется по таймеру 2 раза в секунду, проц не грузит.

[zub]

>>Заполнение 15К узлов занимает мелкую долю секунды и выполняется по таймеру 2 раза в секунду, проц не грузит.
У меня заполнение проходит после добавления примитива в БД чертежа, или после изменения примитива. Чертишь мышкой, а она (мышка) при добавлении примитива на еле заметную долю секунды подвисает-дергается, неудобно.

Сама прорисовка дерева проходит незаметно. "Проблема" с подходом в лоб - перестройка дерева по любому чиху

[serbod]

Сделай очередь действий (команд) и обработчик по таймеру или в отдельном потоке. Тогда ты можешь "откладывать" действия и обрабатывать их не сразу, а во время простоя (по таймеру) или в фоновом процессе. Как приятный бонус - появляется возможность вести журнал действий, делать отмену. У меня действия текстовые, как в командной строке - быстродействия хватает с избытком и никаких проблем с передачей и хранением.

Или используй стандартные команды-сообщения PostMessage(), по крайней мере они не будут тормозить GUI.

[Sharfik]

"Я удалился", "Я изменился" - потребуют поиска себя в дереве. если из 5000 устройств разом изменится 500 - этот поиск съест весь выигрыш и превратит его в проигрыш.
Или придется хранить в примитивах их ноды в навигаторах. Что тоже непросто. примитив ниче о навигаторах не знает и знать недолжен

Неправильно ты шеф мыслишь.
Устройство изменяется не само, а по команде пользователя. При выполнении команды в конце действий дописываешь обращение к функции SendNotify(Кто,ЧтоСделал)
Навигатор когда создается, то добавляет себя в список получателей оповещений. Дальше SendNotify при боработке рассылает всем зарегестрированным получателям информацию. А вот что с ней делать уже каждый решает сам. Либо перерисовывать полностью себя, либо найти виновника и "наказать" персонально.

У меня в проекте менеджера данных каждая таблица имеет такой список "Получателей" и когда очередной TVirtualStringTree появляется в проекте он обновляется через такие уведомления. Единственно что данные как и сказал serbod - отрисовываются по факту состояния в памяти.

У Нанокад Электро беда была такая, в одном месте название поменяешь группы, а в другом окне оно как раньше отображается.

[zub]

>>Неправильно ты шеф мыслишь.
Я мыслю абсолютно также как ты расписал.
До момента:
>>Либо перерисовывать полностью себя, либо найти виновника и "наказать" персонально.
только не перерисовывать, а пересоздавать
Вот в наше TЧетоТамTree пришло извещение что вот этот TObject изменился. И нам нам надо изменить\переместить\персоздать асоциированную с этим TObject ноду.
Но перед этим эту ноду надо найти.

[serbod]

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

[zub]

Да, оновление будет в онидле и только для видимого.

[Sharfik]

Я мыслю абсолютно также как ты расписал.
До момента:
>>Либо перерисовывать полностью себя, либо найти виновника и "наказать" персонально.
только не перерисовывать, а пересоздавать
Вот в наше TЧетоТамTree пришло извещение что вот этот TObject изменился. И нам нам надо изменить\переместить\персоздать асоциированную с этим TObject ноду.
Но перед этим эту ноду надо найти.

Как я понял, у тебя узлами есть. Значит верхний узел по какому то принципу подбирается. А значит обходить всех не надо, надо сначала обойти только верхние узлы и потом копаться в одном конкретном.
А по какому признаку происходит поиск?

[zub]

На данный момент у меня 2 настройки группировки - по префиксу и базовому имени. Если их выключить узлов не будет, или если пользователь не использует префиксы а тупо сразу вбивает требуемое имя - узлов тоже небудет. Такчто на узлы лучше не надеется.
В нодах у меня хранится адрес и имя соответствующего устройства (на имя надежды нет, т.к. одноименные устройства не запрещены), поэтому оптимально наверно будет дополнительно хранить мапу соответствий адрес устройства -> нода c быстрым двоичным поиском. Но это снова серъезные расходы на пересоздание

ИМХО адрес ноды лучше всего хранить в примитиве

Добавлено спустя 11 минут 42 секунды:
https://imgur.com/a/KCyx7

Добавлено спустя 24 секунды:
Гебольшое пояснение по группировкам. на "чертеже" 16 "шкафов" с префиксамии от 1 до 4, базовыми именами ША, ШУ и суфиксами от 1 до 4. обозначение шкафов формируется как префикс+базовое имя+суфикс. Доступны группировки по префиксу и базовому имени, но они могут быть выключены и "дерево" становится линейным "списком"

[vitaly_l]

"Проблема" с подходом в лоб - перестройка дерева по любому чиху

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

[ElectroGuard]

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

[zub]

Отложеная перестройка дерева проблему решает. Поэтому пока оставлю "навигаторов" как есть.

По замечаниям появилась возможность относительного ввода координат в командную строку, декартовых и полярных:
@x,y
@x,y,z
@длина<угол
Сам никогда не пользовал, но некоторым оказывается надо

[olegy123]

"Я удалился", "Я изменился" - потребуют поиска себя в дереве. если из 5000 устройств разом изменится 500 - этот поиск съест весь выигрыш и превратит его в проигрыш.
Или придется хранить в примитивах их ноды в навигаторах. Что тоже непросто. примитив ниче о навигаторах не знает и знать недолжен

Zub еще не разу не прфилировал свою программу?
что за безобразие?! это возмутительно?! как это низко..

Zub - компутер так устроен, что у него в каждую секунду что-то меняется, что-то на что-то складывается, делится или умножается.. ищется и сравнивается тоже.И ему нужно работать с большими таблицами. Как проигрывается HD/2K/4K видео..там по 24/30/60/120 раз нужно рефрешить цвета в большой матрице. Да еще гонять по шине - более 26мб болше 30 раз в секунду.

15К устройств - это не так много..

профилирование тебе откроет где процик упахивается, может за зря.

Добавлено спустя 35 минут 46 секунд:

Да, оновление будет в онидле и только для видимого.

Плохой вариант.
Вытащи рефреш в отдельный поток. тем самым скорость отрисовки вообще не будет зависеть от скорости в главном потоке.