0001495: Список меток сделать таблицей

Notes
(0016121) zed (manager) 11-07-2015 07:28	Я вот думаю, что когда в Управлении метками мы начнём использовать VirtualTreeView (см. 0002461), то сделать табличный вид будет вполне просто и логично. Правда, категории останутся отдельно, а метки отдельно, как и сейчас. Это не совсем то, что просил топикстартер, но очень близко.

(0016128) vasketsov (manager) 11-07-2015 12:18 edited on: 11-07-2015 12:20	>Столбцы: >3. Категория Хм. Может быть сделать многомерный КУБ, и вращайте его как хотите, группируйте по категории или по атрибутам, типам,... >сделать табличный вид будет вполне просто и логично Ничего проще и быстрее дбгрида не получится.

(0016130) zed (manager) 11-07-2015 12:24	И как ты предлагаешь вкорячить этот DBGrid? Ему же DataSource нужен, а у нас из базы интерфейсы возвращаются.

(0016133) vasketsov (manager) 11-07-2015 12:39	>у нас из базы интерфейсы возвращаются Вы так об этом говорите, как будто это правильно ;) Кто сказал, что тот же самый API, что используется для показа меток, является самым оптимальным для отображения данных в виде куба или таблицы? Сначала значит суём метки в список, потом итератор запускаем по списку, потом суём в дерево... Задача - заполнить датасет из базы. Как это будет сделано технически - по большому счёту не принципиально. Главное - надо не грид заполнять на основе полученного списка, а чтобы грид (через датасет) отдавался в базу и говорил: "Заполните меня напрямую!" Только тогда это будет реально быстро. Кроме того, появится возможность подгружать данные по мере необходимости (а не ждать построения всего дерева прежде чем его показать). А вообще, поскольку редактирование в гриде не предполагается, то можно датасет даже руками наполнять на основании списка интерфейсов, и то что там всё будет в состоянии dsEdit, парить не должно.

(0016136) zed (manager) 11-07-2015 13:07	Ну пока никто не собирается менять API подсистемы меток для оптимизации отображения, VirtualTreeView должен вписаться вполне нормально. Не идеально, но хуже чем сейчас, точно не будет.

(0016138) vasketsov (manager) 11-07-2015 13:36	>хуже чем сейчас, точно не будет Когда-то давно он был настолько баговит, что мне от него пришлось отказаться. >VirtualTreeView должен вписаться вполне нормально Ну и в чём разница тогда, его заполнять из списка или пустой датасет? Делать, так сразу полноценный грид.

(0016139) zed (manager) 11-07-2015 13:39	Датасет нужно заполнить полностью, а это дерево будет заполняться динамически, по мере надобности.

(0016140) vasketsov (manager) 11-07-2015 18:04	>дерево будет заполняться динамически Это как? Дерево принципиально строится полностью до показа, потому что процедура типа append для него в общем случае не определена. Если мы опять приходим к тому, что мы будем с деревом работать как с гридом, то на кой вообще тогда такое дерево, если можно сразу взять грид? >Датасет нужно заполнить полностью С чего бы это? Грид как раз позволяет не грузить всё в датасет перед отображением. Да вот даже хотя бы в датасет запульнуть только идентификатор метки или номер в списке, а остальные поля сделать кальковыми, и на OnCalcFields заполнять их из списка. Чего влазит в клиентскую область - то и будет отображаться.

(0016141) zed (manager) 11-07-2015 18:42	> Дерево принципиально строится полностью до показа Этот компонент хитрый - ты ему указываешь количество нодов и назначаешь обработчик OnInitNode, а он вызывает твой код, где ты инициализируешь только те ноды, которые реально отображаются на экране. Так что и строится оно на лету.

(0016158) vasketsov (manager) 14-07-2015 07:33	>ты ему указываешь количество нодов >назначаешь обработчик OnInitNode >инициализируешь только те ноды, которые реально отображаются на экране И чем это принципиально отличается от OnCalcFields у DBGrid?

Users who viewed this issue
User List	Anonymous (2700x), vdemidov (10x), zarius (6x), ygorigor (3x), Papazol (2x), echo (1x), Garl (2x), zed (22x), gma (1x), netsky (1x), vasketsov (20x), bk99 (1x)
Total Views	2769
Last View	21-11-2024 09:30

Issue History
Date Modified	Username	Field	Change
12-08-2012 18:42	koch	New Issue
03-09-2012 10:45	vdemidov	Status	new => resolved
03-09-2012 10:45	vdemidov	Resolution	open => won't fix
03-09-2012 10:45	vdemidov	Assigned To	=> vdemidov
03-09-2012 10:45	vdemidov	Status	resolved => closed
11-07-2015 07:28	zed	Note Added: 0016121
11-07-2015 07:29	zed	Relationship added	parent of 0002461
11-07-2015 07:29	zed	Assigned To	vdemidov =>
11-07-2015 07:29	zed	Status	closed => confirmed
11-07-2015 07:30	zed	Resolution	won't fix => reopened
11-07-2015 07:30	zed	Target Version	=> 151010
11-07-2015 12:18	vasketsov	Note Added: 0016128
11-07-2015 12:19	vasketsov	Note Edited: 0016128	View Revisions
11-07-2015 12:20	vasketsov	Note Edited: 0016128	View Revisions
11-07-2015 12:24	zed	Note Added: 0016130
11-07-2015 12:39	vasketsov	Note Added: 0016133
11-07-2015 13:07	zed	Note Added: 0016136
11-07-2015 13:36	vasketsov	Note Added: 0016138
11-07-2015 13:39	zed	Note Added: 0016139
11-07-2015 18:04	vasketsov	Note Added: 0016140
11-07-2015 18:42	zed	Note Added: 0016141
14-07-2015 07:33	vasketsov	Note Added: 0016158
29-07-2015 14:53	vdemidov	Tag Attached: метки
29-07-2015 14:53	vdemidov	Tag Attached: управление метками
24-09-2015 07:18	vdemidov	Target Version	151010 => 40xxxx

SASGIS