|
Notes |
|
|
(0016121)
|
|
zed
|
|
11-07-2015 07:28
|
|
|
Я вот думаю, что когда в Управлении метками мы начнём использовать VirtualTreeView (см. 0002461), то сделать табличный вид будет вполне просто и логично. Правда, категории останутся отдельно, а метки отдельно, как и сейчас. Это не совсем то, что просил топикстартер, но очень близко. |
|
|
|
(0016128)
|
|
vasketsov
|
11-07-2015 12:18
(edited on: 11-07-2015 12:20) |
|
>Столбцы:
>3. Категория
Хм. Может быть сделать многомерный КУБ, и вращайте его как хотите, группируйте по категории или по атрибутам, типам,...
>сделать табличный вид будет вполне просто и логично
Ничего проще и быстрее дбгрида не получится.
|
|
|
|
(0016130)
|
|
zed
|
|
11-07-2015 12:24
|
|
|
И как ты предлагаешь вкорячить этот DBGrid? Ему же DataSource нужен, а у нас из базы интерфейсы возвращаются. |
|
|
|
|
>у нас из базы интерфейсы возвращаются
Вы так об этом говорите, как будто это правильно ;)
Кто сказал, что тот же самый API, что используется для показа меток, является самым оптимальным для отображения данных в виде куба или таблицы? Сначала значит суём метки в список, потом итератор запускаем по списку, потом суём в дерево...
Задача - заполнить датасет из базы. Как это будет сделано технически - по большому счёту не принципиально. Главное - надо не грид заполнять на основе полученного списка, а чтобы грид (через датасет) отдавался в базу и говорил: "Заполните меня напрямую!" Только тогда это будет реально быстро. Кроме того, появится возможность подгружать данные по мере необходимости (а не ждать построения всего дерева прежде чем его показать).
А вообще, поскольку редактирование в гриде не предполагается, то можно датасет даже руками наполнять на основании списка интерфейсов, и то что там всё будет в состоянии dsEdit, парить не должно. |
|
|
|
(0016136)
|
|
zed
|
|
11-07-2015 13:07
|
|
|
Ну пока никто не собирается менять API подсистемы меток для оптимизации отображения, VirtualTreeView должен вписаться вполне нормально. Не идеально, но хуже чем сейчас, точно не будет. |
|
|
|
|
>хуже чем сейчас, точно не будет
Когда-то давно он был настолько баговит, что мне от него пришлось отказаться.
>VirtualTreeView должен вписаться вполне нормально
Ну и в чём разница тогда, его заполнять из списка или пустой датасет? Делать, так сразу полноценный грид. |
|
|
|
(0016139)
|
|
zed
|
|
11-07-2015 13:39
|
|
|
Датасет нужно заполнить полностью, а это дерево будет заполняться динамически, по мере надобности. |
|
|
|
|
>дерево будет заполняться динамически
Это как? Дерево принципиально строится полностью до показа, потому что процедура типа append для него в общем случае не определена. Если мы опять приходим к тому, что мы будем с деревом работать как с гридом, то на кой вообще тогда такое дерево, если можно сразу взять грид?
>Датасет нужно заполнить полностью
С чего бы это?
Грид как раз позволяет не грузить всё в датасет перед отображением.
Да вот даже хотя бы в датасет запульнуть только идентификатор метки или номер в списке, а остальные поля сделать кальковыми, и на OnCalcFields заполнять их из списка. Чего влазит в клиентскую область - то и будет отображаться. |
|
|
|
(0016141)
|
|
zed
|
|
11-07-2015 18:42
|
|
> Дерево принципиально строится полностью до показа
Этот компонент хитрый - ты ему указываешь количество нодов и назначаешь обработчик OnInitNode, а он вызывает твой код, где ты инициализируешь только те ноды, которые реально отображаются на экране. Так что и строится оно на лету. |
|
|
|
|
>ты ему указываешь количество нодов
>назначаешь обработчик OnInitNode
>инициализируешь только те ноды, которые реально отображаются на экране
И чем это принципиально отличается от OnCalcFields у DBGrid? |
|