Всем привет!

Кто-нить делал себе тривью-контрол полностью на фоксе внешне выглядящую как ActiveX от мелкомягких? Видел (в решениях) тривьющку на гриде - хорошо, но видуха не та )))

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



Исправлено 1 раз(а). Последнее : AndyNigmatec, 14.07.17 11:35

В решения посмотри, было

AndyNigmatec
Всем привет!
Кто-нить делал себе тривью-контрол полностью на фоксе внешне выглядящую как ActiveX от мелкомягких? Видел (в решениях) тривьющку на гриде - хорошо, но видуха не та )))

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

Быстродействие на этом ActiveX можно немного увеличить, если в момент заполнения сделать контрол невидимым. Ну еще как вариант это динамически "подгружать" ветки дерева.

Народ, ну я же сразу пояснил - интересует именно НЕ-активикс TreeView ... с активиксом давно и нормально все работает )))
В решениях кстати тож все на активикс-контроле (кроме тривьюшки на гриде)

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



Исправлено 1 раз(а). Последнее : AndyNigmatec, 14.07.17 11:51

AndyNigmatec
прошлось себе нарисовать ...

А что нам прикажите гадать, чего это он там "нарисовал" ...

В этой ветке Xandy выкладывал для ограниченного по высоте дерева.
forum.foxclub.ru

Там же было моё решение для неограниченного по высоте дерава. Решения скрестить можно.

dimuhametov
А что нам прикажите гадать, чего это он там "нарисовал" ...

написал выше

суть то вопроса - скорость работы с обьектами в контейнере - AddObject()-RemoveObject() - медленно как-то

pasha_usue
В этой ветке Xandy выкладывал для ограниченного по высоте дерева.

- да видел, это на гриде - хотел поначалу его и взять ... но вот захотелось некоторым (не будем показывать пальцем) чтоб внешне осталось "как былО"

AndyNigmatec

pasha_usue
В этой ветке Xandy выкладывал для ограниченного по высоте дерева.

- да видел, это на гриде - хотел поначалу его и взять ... но вот захотелось некоторым (не будем показывать пальцем) чтоб внешне осталось "как былО"

Если убрать RecordMark и границы колонок, то будет почти как було.

Вообще, решение Xandy допилить под свои нужды.
И будет тебе скорость.
Сомневаюсь что лучше него кто то UI рисует)))

Для большей конкретики прикреплю что покамест получилось ...

[attachment 27971 tw.png]



Исправлено 1 раз(а). Последнее : AndyNigmatec, 14.07.17 12:38

Аспид
Сомневаюсь что лучше него кто то UI рисует)))

ну уж точно не я

тут с простыми то вещами ковыряюсь ...

В дотнете treeview входит в стандартные контролы.

И в чем отличие от решения Андрея?
Визуально почти один в один.
Причем у него возможности допиливать, невообразимые.
И все летает

AndyNigmatec

Аспид
Сомневаюсь что лучше него кто то UI рисует)))

ну уж точно не я

тут с простыми то вещами ковыряюсь ...

Фокс очень плохо работает с большим количеством объектов. Тем более, если они вложены. Поэтому, либо создавать окно видимости, либо грид работает на порядок быстрее.

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

"Проблема сисадминов" ограничивается запретом кидать файлы в system32 и доступом к реестру?

Если да (что в принципе вполне адекватно), то вместо отказа от активикса стоит отказаться лишь от его регистрации в системе, используя подход RegFreeCom (добавить к exe свой манифест).

Если нет (и они лезут в твой проект и смотрят какие же ты там dll да ocx используешь ), то тебе не повезло. Решения на основе кучи фоксовых контролов (хватит всего нескольких сотен чтобы ощутить все "прелести") в контейнере будут априори тормознутые.

AndyNigmatec
прошлось себе нарисовать ... так чтоб еще внешне не сильно отличалось. И все бы ничего - но быстродействие полученного печальное (ежели нод более нескольких сотен), вот и интересуюсь - делал ли кто-нить подобное и если делал - то как с быстродействием?

Возможно просто код у тебя не оптимизирован. Если бы привел хотя бы структуру своего построения, можно было бы попытаться поискать проблемы и возможности для оптимизации.
В принципе, глядя на твою картинку, появилась и еще одна идея несколько другого подхода к такому построению. Но для проверки как всегда нужно свободное время и подходящее под это время желание поэкспериментировать.

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

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

И таки две ну очень серьезные ошибки у тебя там! Думаю, если бы правильно все сделать, даже без гридового дерева, вполне можно было бы сваять при желании очень даже себе быстрое дерево. ;)
Во-первых у тебя нарушен первый принцип отображения.
Ну это как бы мое собственное название, можешь не искать нигде по таким словам. Тем не менее, он используется обычно везде, где нужно сделать быстрый просмотр - в любых нормальных редакторах и прочем.
Суть его такова: "Никогда не просчитывать целиком всю мыслимую область отображения".
Или по армейски: "Задачи надо решать по мере их поступления".
Поскольку, как известно, при отображении чего-то все тормоза идут только через отображение, непосредственно же код для перерисовки обычно выполняется мгновенно. Значит надо просто как можно меньше рисовать после клика.
Т.е. нафига вычислять (и затем рисовать) все дерево от корней до листьев для всей таблицы??! все равно его не видно за пределами бокса. Вычислять надо только для видимой области. При листании же - вычислять следующую часть. Вычисляется мгновенно в момент клика. А отображение объектов такой маленькой области также происходит достаточно быстро.
Таким образом был когда-то сделан BROWSE в FPD - вещь просто-таки невероятная по скорости отображения, когда на ужасно черепаховых машинах можно было спокойно себе листать базу данных размером в миллион записей. Многие программы в то время вешались при просмотре текстового файла таких размеров. Потому что не использовали этот принцип и вычисляли при любом движении все от начала до конца.
Вторая твоя непонятность и похоже ошибка - нафига тебе там столько таймеров?!
Каждый таймер так или иначе создает какие-то тормоза, а уж если их там понапихано мильоны, какой уж скорости требовать.
Пока конечно не вникал во все нюансы твоего кода, но такое ощущение, что там таймеры и вообще не нужны. Если хорошенько подумать. ;)
Ну т.е., если есть желание на досуге позаниматься, думаю вполне себе скоростное дерево можно слепить даже и средствами фокса. Если не нарушать основные принципы работы с отображением.