Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 25.02.04 12:01
Оценка:
Вот ищу сабж. Основные требования:
В общем требований немного Редактирования, группирования данных и прочих изысков не надо. Желательно что бы грид был с исходниками.
Покопал на www.codeproject.com, ничего хорошего не нашел. Сейчас смотрю на TreeGrid из януса. Вроде бы пока вполне устраивает (на сколько я знаю его использование не запрещено ), но это все-таки Tree грид и возиться с ITreeNode особой необходимости нет.
В общем может ли мне кто-нибудь порекомендовать хороший грид?
... << RSDN@Home 1.1.3 beta 1 >>

12.05.04 06:46: Перенесено модератором из '.NET GUI' по просьбам трудящихся — OE
Re: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.04 20:56
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Вот ищу сабж. Основные требования:

SAV> SAV>В общем требований немного Редактирования, группирования данных и прочих изысков не надо. Желательно что бы грид был с исходниками.
SAV>Покопал на www.codeproject.com, ничего хорошего не нашел. Сейчас смотрю на TreeGrid из януса. Вроде бы пока вполне устраивает (на сколько я знаю его использование не запрещено ), но это все-таки Tree грид и возиться с ITreeNode особой необходимости нет.
SAV>В общем может ли мне кто-нибудь порекомендовать хороший грид?

Могу только скзать как рзаработчик того самого TreeGrid, что по описанию он вроде то что тебе надо. То что он Tree особой роли не играет. В ХМЛ правда колонки не сохраняет, но думаю тебе особого труда не составит преобразовать массив целых в ХМЛ. Что же касается возни с ITreeNode, то без нее можно обойтись использую класс SimpleNode. Но если записей будет действительно много, то свой класс неализующий ITreeNode намного удобнее.

Что касается "на сколько я знаю его использование не запрещено ", то да бесплатный. Буду рад если укажешь ссылку на rsdn.

Качественной халявы я не видел. Иначе бы в качестве основы для TreeGrid ее бы и использовал. Если Al-Ko таки сделает виртуальную прослойку, то модно будет использовать ее (подробности здесь
Автор: Al-Ko
Дата: 29.01.04
).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 26.02.04 12:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Могу только скзать как рзаработчик того самого TreeGrid, что по описанию он вроде то что тебе надо.

Да вот по-видимому все же не подойдет. Мне необходимо отображать списки (они у меня реализуют IBindingList). Элементы в них могут быть довольно таки различные и прикручивать к ним ITreeNode, видимо не получится.

VD>Что же касается возни с ITreeNode, то без нее можно обойтись использую класс SimpleNode. Но если записей будет действительно много, то свой класс неализующий ITreeNode намного удобнее.

Записей может быть очень много.

VD>Что касается "на сколько я знаю его использование не запрещено ", то да бесплатный. Буду рад если укажешь ссылку на rsdn.

Если все-таки буду использовать, то укажу

VD>Качественной халявы я не видел.

Как говорится, кто если не мы
VD>Иначе бы в качестве основы для TreeGrid ее бы и использовал. Если Al-Ko таки сделает виртуальную прослойку, то модно будет использовать ее (подробности здесь
Автор: Al-Ko
Дата: 29.01.04
).

Я вчера вечерком долго читал этот тред, много думал Идея мне понравилась, а так как грид меня пока не торопит (я сделал обертку над стандартным и все бы ничего, но эта тварь никак не хочет работать в виртуальном режиме. А когда будет подходящий грид, заменить им стандартный будет недолго), то я бы с удовольствием принял участие в разработке "качественной халявы" Только все наверное опять упрется в руководителя проекта...
... << RSDN@Home 1.1.3 beta 1 >>
Re[3]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 13:09
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Да вот по-видимому все же не подойдет. Мне необходимо отображать списки (они у меня реализуют IBindingList). Элементы в них могут быть довольно таки различные и прикручивать к ним ITreeNode, видимо не получится.


А в чем проблема? Сделай на худой конец адаптер IBindingList -> ITreeNode.

VD>>Что же касается возни с ITreeNode, то без нее можно обойтись использую класс SimpleNode. Но если записей будет действительно много, то свой класс неализующий ITreeNode намного удобнее.

SAV>Записей может быть очень много.

Тогда выкидывай к чертям этот IBindingList и реализуй ITreeNode. Он оптимизирован на огромные количества записей. Хранение данных можно сделать очень компактно.

VD>>Качественной халявы я не видел.

SAV>Как говорится, кто если не мы

Т.е. у нас появится еще один гридописатель?

SAV>Я вчера вечерком долго читал этот тред, много думал Идея мне понравилась, а так как грид меня пока не торопит (я сделал обертку над стандартным и все бы ничего, но эта тварь никак не хочет работать в виртуальном режиме.


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

SAV> А когда будет подходящий грид, заменить им стандартный будет недолго), то я бы с удовольствием принял участие в разработке "качественной халявы" Только все наверное опять упрется в руководителя проекта...


Не, ну, на руководство меня хватит. Так что если сговоритесь с Al-Ko, то будет вам помощь со стороны команды RSDN и от меня лично.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 26.02.04 13:17
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Не, ну, на руководство меня хватит. Так что если сговоритесь с Al-Ko, то будет вам помощь со стороны команды RSDN и от меня лично.

ну так делаем!
... << RSDN@Home 1.1.3 beta 1 >>
Старый глюк лучше новых двух!
Re[4]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 26.02.04 14:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А в чем проблема? Сделай на худой конец адаптер IBindingList -> ITreeNode.

Да я уже новым гридом загорелся

VD>Тогда выкидывай к чертям этот IBindingList и реализуй ITreeNode. Он оптимизирован на огромные количества записей. Хранение данных можно сделать очень компактно.

Выкинуть IBindingList не получится, на него у меня много другого завязано, но это уже не важно

VD>Т.е. у нас появится еще один гридописатель?

Считайте уже появился

VD>И не заработает. Его студенты писали, причем китайские. Они на всякий пожарный при подключении датасета приводят все строки к какому-то там интерфейсу (чтобы опредлеить небыло ли ошибки в стоке, чтобы вывадить ее красным кружочком с крестиком).

Да, я как-то помнится пару месяцев назад проводил в этом направлении изыскания и наткнулся на этот цикл... Долго матерился, на этом форуме в том числе

VD>Не, ну, на руководство меня хватит.

Ну иногда консультировать нас по вопросам гридостроения, надеюсь не откажетесь?

VD> Так что если сговоритесь с Al-Ko, то будет вам помощь со стороны команды RSDN и от меня лично.

Думаю сговоримся
... << RSDN@Home 1.1.3 beta 1 >>
Re[5]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 26.02.04 14:11
Оценка:
Здравствуйте, Al-Ko, Вы писали:

VD>>если сговоритесь с Al-Ko, то будет вам помощь со стороны команды RSDN и от меня лично.

AK>ну так делаем!
Как смотришь на то чтобы объединить усилия? Если что стучись в асю (175747164) поболтаем
... << RSDN@Home 1.1.3 beta 1 >>
Re[6]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 26.02.04 14:25
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Как смотришь на то чтобы объединить усилия?

я только за. Если еще нам и проект на РСДН откроют, будет просто супер
SAV>Если что стучись в асю (175747164) поболтаем
у меня нет аськи
... << RSDN@Home 1.1.3 beta 1 >>
Старый глюк лучше новых двух!
Re[7]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 26.02.04 14:42
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>у меня нет аськи

Жалко... Тогда остается мыло и любимый РСДН У тебя мыло в профайле живое? туда можно писать?
... << RSDN@Home 1.1.3 beta 1 >>
Re[8]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 26.02.04 15:00
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Здравствуйте, Al-Ko, Вы писали:


AK>>у меня нет аськи

SAV>Жалко...
че-то боюсь я ее себе ставить И вирусы, говорят, от этого бывают
SAV>Тогда остается мыло и любимый РСДН У тебя мыло в профайле живое? туда можно писать?
сюда лучше:
autosoft<a>ukrlink.com
... << RSDN@Home 1.1.3 beta 1 >>
Старый глюк лучше новых двух!
Re[5]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:02
Оценка:
Здравствуйте, SiAVoL, Вы писали:

VD>>Не, ну, на руководство меня хватит.

SAV>Ну иногда консультировать нас по вопросам гридостроения, надеюсь не откажетесь?

Дык я врод уже этим занимаюсь.

VD>> Так что если сговоритесь с Al-Ko, то будет вам помощь со стороны команды RSDN и от меня лично.

SAV>Думаю сговоримся

Ну, тады пошел говорить с нашими об открытии нового проекта.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:02
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Здравствуйте, Al-Ko, Вы писали:


AK>>у меня нет аськи

SAV>Жалко... Тогда остается мыло и любимый РСДН У тебя мыло в профайле живое? туда можно писать?

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

Другое дело, что форум нужно использовать не этот. Иначе потом нифига не найдешь. Нужно или перемещаться в RSDN Research, или создавать новый.

Кстати, первым пунктом создания проекта должна быть статься описывающая цели, и средства. Ну, что-то на подобии этого: Проект R#
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004
.

Кто возьмется?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Простой, быстрый, бесплатный грид
От: Воронков Василий Россия  
Дата: 26.02.04 15:12
Оценка:
"VladD2" <73@news.rsdn.ru> wrote in message news:552078@news.rsdn.ru...

> Ну, тады пошел говорить с нашими об открытии нового проекта.


Я ж говорю, что workspaces нужны
Posted via RSDN NNTP Server 1.8 beta
Re[9]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 26.02.04 15:30
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Другое дело, что форум нужно использовать не этот. Иначе потом нифига не найдешь. Нужно или перемещаться в RSDN Research, или создавать новый.

есть же форум проектов

VD>Кстати, первым пунктом создания проекта должна быть статься описывающая цели, и средства. Ну, что-то на подобии этого: Проект R#
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004
.

VD>Кто возьмется?
я
... << RSDN@Home 1.1.3 beta 1 >>
Старый глюк лучше новых двух!
Re[7]: Простой, быстрый, бесплатный грид
От: Andre Украина  
Дата: 26.02.04 15:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я ж говорю, что workspaces нужны


Так что заодно и проект написания workspaces ?
... << RSDN@Home 1.1.3 beta 2 >> :: ...
Я бы изменил мир — но Бог не даёт исходников...
Re[10]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:16
Оценка: -1
Здравствуйте, Al-Ko, Вы писали:

AK>есть же форум проектов


Там ИТ окопался. Будем постоянно пересекаться. Лучше уж ресерч.

AK>я


Давай. Но не затягивай. Если что неполучается, говори... обсудим.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:16
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я ж говорю, что workspaces нужны


Чё?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Простой, быстрый, бесплатный грид
От: Воронков Василий Россия  
Дата: 26.02.04 17:41
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Я ж говорю, что workspaces нужны


VD>Чё?


типа сурсфорджа, только сделанное не кривыми руками
... << RSDN@Home 1.1.3 beta 1 >>
Re[11]: Простой, быстрый, бесплатный грид
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.04 12:14
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Там ИТ окопался. Будем постоянно пересекаться.


Это как? Типа IT будет специально гадить в ветки про контрол, а вы в ветки про RFD?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[9]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 27.02.04 18:31
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Кстати, первым пунктом создания проекта должна быть статься описывающая цели, и средства. Ну, что-то на подобии этого: Проект R#
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004
.


VD>Кто возьмется?


я отправил на vc(at)rsdn.ru текст статьи для согласования. Нужно добавить технические подробности (см.последний пункт статьи)
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[12]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.04 19:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это как? Типа IT будет специально гадить в ветки про контрол, а вы в ветки про RFD?


Это так. В его сообщениях особых намеков на проект нет. В моих тоже. Будут все время путаться.

В общем, по уму для каждого проекта нужен отдельный форум.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Простой, быстрый, бесплатный грид
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.04 19:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это так. В его сообщениях особых намеков на проект нет. В моих тоже. Будут все время путаться.


Пишите префиксы в темах и не будет никакой путаницы.
... << RSDN@Home 1.1.3 beta 2 (mobile station) >>
AVK Blog
Re[14]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.04 22:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Пишите префиксы в темах и не будет никакой путаницы.


Ну, на фиг такой бардак? Темболее что все старые темы без префиксов.

В чем проблема то под проект по форуму сделать?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.04 22:55
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>я отправил на vc(at)rsdn.ru текст статьи для согласования. Нужно добавить технические подробности (см.последний пункт статьи)


У нас тут перезд на новый сервер. Почта неработает.

Публику пока что здесь.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 28.02.04 10:26
Оценка: 51 (2) +1
Здравствуйте, VladD2, Вы писали:

Вот текст:

Проект VirtualGrid.Net
Виртуальный грид

Введение

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

Еще один грид?

Существует множество контролов-гридов, поставляющихся как в стандартных пакетах средств разработки, так и в продуктах сторонних производителей. Все они имеют свои бесспорные достоинства, равно как и недостатки. В данной статье мы не будем останавливаться на их обсуждении. Однако, факт остается фактом: несмотря на кажущуюся насыщенность рынка, хороший грид до сих пор востребован сообществом программистов.
В основном, требования к гриду выдвигаются такие:
" Поддержка виртуального режима
" Хорошая скорость отображения
" Возможность отображения данных различных типов
" Возможность редактирования информации
" Небольшая стоимость (что тоже немаловажно)
В задачу этого проекта не входит изготовление очередной "серебрянной пули", панацеи от всех программистких бед, связанных с гридом. Мы попытаемся последовательно подойти к разработке этого сложного и интересного компонента, выделив, в первую очередь, базовую сущность — VirtualGrid.

Что такое VirtualGrid и зачем он нужен?

VirtualGrid — абстрактный базовый класс, предназначенный для реализации общих для всех многострочных контролов механизмов:
" виртуальный режим
" управление отрисовкой
" управление навигацией/скроллингом
" управление фокусом ввода и подсветкой (Highlighting)
" управление коллекцией столбцов

Виртуальный режим

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

Управление отрисовкой

Несмотря на то, что VirtualGrid наследуется от класса контрола WindowsForms, непосредственно выводом на экран он не занимается. VirtualGrid лишь абстрагирует отрисовку, перенося процесс вывода на экран "на плечи" контрола-наследника, который и используется в приложении. Общаясь с контролом-наследником, VirtualGrid при помощи специального callback-интерфейса, посылает ему события на отрисовку очередной строки, ячейки и т.д. Cложной задачей здесь является поддержка строк переменной высоты. В этом случае, целесообразно кэшировать значения этих высот во время первой отрисовки строк. Также важна задача оптимизация области перерисовки при навигации и скроллинге.

Управление навигацией и скроллингом

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

Управление фокусом ввода и подсветкой (Highlighting)

Анализируя сообщения клавиатуры и мыши, VirtualGrid должен управлять перемещением фокуса активной ячейки или строки грида и подсветкой отдельных отмеченных ячеек. Поскольку виртуальный грид абстрактен, он должен опять-таки только сообщать контролу-наследнику о грядущих изменениях, связанных с фокусом или подсветкой ячеек. А контрол-наследник уже сам заботится об отображении этих изменений.

Управление коллекцией столбцов

В отличие от строк, виртуальный грид должен хранить самую полную информацию о данных своих столбцов, поддерживая их полноценную коллекцию, сериализуемую в код. Помимо своего целочисленного индекса, столбцы должны быть именованы, грид должен знать их ширину, располагать информацией о хидерах и футерах. Также необходимо учитывать, что заголовки столбцов могут быть составными и "склееными" между соседними колонками.

Зачем нужен VirtualGrid?

Выделение VirtualGrid в отдельную абстрактную сущность возникло в результате объектной декомпозиции грида как элемента управления табличными данными. Виртуальный грид берет на себя все общие проблемы, оставляя контролам-наследникам место для конкретной реализации. Такие реализации могут быть самыми разнообразными: от TreeGrid, редактируемых прямоугольных гридов и спридшитов до текстовых многострочных редакторов или в конце концов поля для игры в Minesweeper .
Мы хотели бы разделить данные, их представление и "систему управления" гридом, для того, чтобы облегчить разработку контролов-наследников. Это и является основной целью данного проекта.

Особенности проекта VirtualGrid

Информация и структура workspace?
Информация о CVS
Информация о форуме
и т.д.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[12]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 11:31
Оценка: +1
Здравствуйте, Al-Ko, Вы писали:

В целом хорошо. Но нужна более детальная спецификация, т.е. набор трвебований в более формализованом виде. Возможно в виде таблички.

Нужно выделить список фич и описать каждую в отдельности. Например:

Строки могут быть:
    Все строки могут:
        Иметь как различную, так и фиксированную высоту.
        ...
    Обычними (основными). 
        Основные строки могут:
            Прокручиваться относительно области отображения.
            ...
        Фиксированные строки:
            Неподвижны и всегда видны в области отображения.
            ...
            Делятся на:
                Нижние.
                Верхние.
                    Делятся на строки заголовка таблицы (колонки).
                    Пользовательские.
                    ...


В общем, в таком духе. Причем нужно стараться выделять фичи так, чтобы их можно было реализовывать поотдельности (последовательно или параллельно).

Далее нужно выделить этапы. Ну, там проектирование интерфейсов. Проктирование, фич. Реализация фич: х, у... Причем все это нужно подгадать так, чтобы максимально быстро можно было бы получить рабочий прототип.


Так же нужно более четко описать набор контролов-наследников. Возможно даже с указанием тех приемуществ которые они получаят от грида. Это позволит более четко сформулировать необходимые требования.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 01.03.04 10:09
Оценка: +1
Здравствуйте, Al-Ko, Вы писали:

AK>VirtualGrid — абстрактный базовый класс, предназначенный для реализации общих для всех многострочных контролов механизмов:

AK>" управление фокусом ввода и подсветкой (Highlighting)
AK>" управление коллекцией столбцов
По поводу этих двух пунктов. Мне кажется стоит оставить возможность наследнику изменить эти механизмы. Т.е. их надо выделить в отдельные абстракции и поставлять с виртуальным гридом стандартную реализацию (по умолчанию). А при желании их можно заменить на что-то свое.

AK>Управление коллекцией столбцов

AK>В отличие от строк, виртуальный грид должен хранить самую полную информацию о данных своих столбцов, поддерживая их полноценную коллекцию, сериализуемую в код. Помимо своего целочисленного индекса, столбцы должны быть именованы, грид должен знать их ширину, располагать информацией о хидерах и футерах. Также необходимо учитывать, что заголовки столбцов могут быть составными и "склееными" между соседними колонками.
Опять же здесь у меня есть сомнения. Мы не сможем в виртуальном гиде предусмотреть все возможные извращения с колонками. Мне кажется от этого надо абстрагироваться
... << RSDN@Home 1.1.3 stable >>
Re[13]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 01.03.04 11:02
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>По поводу этих двух пунктов. Мне кажется стоит оставить возможность наследнику изменить эти механизмы. Т.е. их надо выделить в отдельные абстракции и поставлять с виртуальным гридом стандартную реализацию (по умолчанию). А при желании их можно заменить на что-то свое.

так и будет

SAV>Опять же здесь у меня есть сомнения. Мы не сможем в виртуальном гиде предусмотреть все возможные извращения с колонками. Мне кажется от этого надо абстрагироваться

все правильно. Пока точно не знаю как, но предусматривается вынести механизм склеивания в отдельный класс, скажем, Merger. Наследники будут реализовывать (или дополнять) его в соответствии со своими нуждами.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[14]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 01.03.04 11:24
Оценка: +1
Думается надо по-маленьку сочинять список основных абстракций с обязанностями и кратким интерфейсом. Кстати как у нас с CVS?
... << RSDN@Home 1.1.3 stable >>
Re[15]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 01.03.04 11:53
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Думается надо по-маленьку сочинять список основных абстракций с обязанностями и кратким интерфейсом.

да, сейчас составлю список фич, потом можно и это

SAV>Кстати как у нас с CVS?

пока тихо
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[12]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 01.03.04 17:18
Оценка:
AK>" управление фокусом ввода и подсветкой (Highlighting)

Множественное выделение планируется? Переключение FullRowSelect/CellSelect?


AK>Запрос на получение самих данных ячеек грида происходит непосредственно перед их отрисовкой.


Получение самих данных? По идее, правильнее абстрагироваться на уровне отрисовки, а не только на уровне данных.

Моё видение, может вам пригодится.

PaintRow/GetRowHeight абстрагируют отрисовку ещё на уровне строки. Отрисовка ячеек вызывается уже из PaintRow при необходимости.

PaintCell отрисовывает ячейку по уже заданному CellRectangle.

Для этого из PaintCell вызывается GetCellText.


Таким образом, можно перегрузить по минимуму: только GetCellText. Тогда грид отрисует этот текст своей стандартной реализацией PaintRow->PaintCell. С учётом TextAlignment соответствующего колумна.

А если нужно рисовать что-то гениальное, тогда перегружаем PaintCell или даже PaintRow. В этом случае нужно самом учитывать выравнивание строк по горизонтали/вертикали, состояния выделения и т.д.


AK>Общаясь с контролом-наследником, VirtualGrid при помощи специального callback-интерфейса


Вот мне не понятно, почему с наследником общаться через интерфейс? Для этого есть виртуальные функции. Зачем систему усложнять

AK>Также важна задача оптимизация области перерисовки при навигации и скроллинге.


Это всё фигня по сравнению с мультивыделением. Если мы поддерживаем мультивыделение, нам приходится хранить список выделеных ячеек.

Или номеров ячеек? Ага, вот в том и дело, что не всё так просто. Если наш грид отображает некоторую коллекцию, то на что будем равняться: на номер или на объект-элемент?

Если мы равняемся на номер, то как быть с удалением элемента из середины? Элементы "поедут" вверх, заполняя "пустоту", а номера выделенных элементов останутся на месте.

А если равняемся на элемент, то список же может содержать несколько одинаковых объектов в разных позициях.


Наверное, на номер всё-таки лучше равняться. Но отсюда следуют ещё кое-какие следствия. В общем, похоже, как ни крути, а для каждого элемента списка нужно хранить отдельную кешированную структурку с состоянием: IsSelected, RowHeight.


AK>Основные задачи здесь — определение первой видимой строки


И сдвига первой строки относительно края. Первая строка может начинаться на три пикселя выше края.

AK> вычисление последней видимой строки и оптимальной области, которая должна быть перерисована


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




AK>Управление фокусом ввода и подсветкой (Highlighting)


Опять таки, мультивыделение и FullRowSelect/CellSelect требуют отдельного продумывания.


AK>. Функционал механизма навигации и скроллинга должен быть отделен от реализации грида и вынесен в отдельный класс.


AK>А контрол-наследник уже сам заботится об отображении этих изменений.


Полезно было бы реализовать уже в самом базовом контроле, а наследнику оставить право сделать кастомизацию. В 95% случаев будет использоваться обычная навигация, естественно её внести в базовый класс.

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


Я бы ещё советовал виртуальные методы PaintHeader и PaintHeaderCell. Мало ли что там наследники захотят в отрисовке хидера замухлевать.


AK> Помимо своего целочисленного индекса, столбцы должны быть именованы


Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему


AK> грид должен знать их ширину, располагать информацией о хидерах и футерах.


А также выравнивание текста в соотв. колонках.


AK> Также необходимо учитывать, что заголовки столбцов могут быть составными и "склееными" между соседними колонками.


А вот склееные столбцы можно с чистой совестью оставить на наследников. Есть стандартный PaintHeaderCell, пусть рисуют хоть склееные, хоть перевёрнутые. Логично?


AK>до текстовых многострочных редакторов


Закладываться но текстовые редакторы — это малость маньячеством пахнет. Кто бы не реализовывал редактор, вряд ли ему придёт в голову ивзращаться и наследоваться от грида.



P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.

P.P.S GetRowHeight должен в базовой реализации возвращать константу. Расчитывать от размера текста дорого.
... << RSDN@Home 1.1.3 beta 1 >>
Re[14]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 22:52
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>все правильно. Пока точно не знаю как, но предусматривается вынести механизм склеивания в отдельный класс, скажем, Merger. Наследники будут реализовывать (или дополнять) его в соответствии со своими нуждами.


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

В общем, тут нужно ооочнь серьезно подумать.

Отдельной пробемой является задание всей этой фигни. Задавть это программно дико неудобно. Нужно делать нечто вроде того что сделано в таблицах HTML-я или еще что.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 22:52
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Кстати как у нас с CVS?


Говорят, что сначало нужно более серьезные проблемы решить. Но думаю до следующей недели будет.

Для планирования интерфейсов ЦВС не нужен. Так что с них нужно и начать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 22:52
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Получение самих данных? По идее, правильнее абстрагироваться на уровне отрисовки, а не только на уровне данных.


Это разные абстракции. Мы этим вопросом довольно серьезно занимались на плюса в Активыксовскую эру. Вот результаты: http://www.optim.ru/cs/2002/1/visualcomponents/visualcomponents.asp

M>Моё видение, может вам пригодится.


Любое видение полезно. Даже совсем противопложенное.

M>PaintRow/GetRowHeight абстрагируют отрисовку ещё на уровне строки. Отрисовка ячеек вызывается уже из PaintRow при необходимости.


Согласен. Надо ввести класс RowPainter и отдать ему на расстерзание логику отрисовки строк. Тогда отрисовка и обычных строк и строк заголовков будет универсальна. Это, кстати, классно встраивается в концпцию. Например, если на базе такой модели делать текстовый процессор, то отрисовка на уровне строк будет очень кстати. В нем как раз вся мутата с колонками/ячейками лишняя.

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

M>PaintCell отрисовывает ячейку по уже заданному CellRectangle.


Тоже логично. И поять же отдельный класс с отдельным интерфейсом.

M>Для этого из PaintCell вызывается GetCellText.


Тлько PaintCell это не метод, а класс. Он кстати должен заниматься нехилым кэшированием. Он может хранить строки формата, информацию о шрифте, браши и т.п.

M>Таким образом, можно перегрузить по минимуму: только GetCellText. Тогда грид отрисует этот текст своей стандартной реализацией PaintRow->PaintCell. С учётом TextAlignment соответствующего колумна.


А вот тут не согласен. Стандартных реализаций ненужно вообще. Будут просто реализации. Для текста, для дат, для целых, для денег, для флоата, для картинок, ... Причем все они должны поддерживать стили, чтобы можно было менять множество параметров множества колонок и гридов одним махом.

M>А если нужно рисовать что-то гениальное, тогда перегружаем PaintCell или даже PaintRow. В этом случае нужно самом учитывать выравнивание строк по горизонтали/вертикали, состояния выделения и т.д.


А в моем подходе всего лишь меняем отрисовщик и вуаля!

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

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

M>Вот мне не понятно, почему с наследником общаться через интерфейс? Для этого есть виртуальные функции. Зачем систему усложнять


Потму что не факт, что общаться будет сам наследник. Я могу подснуть вемето него все что угодно. Причем динамически.

AK>>Также важна задача оптимизация области перерисовки при навигации и скроллинге.


M>Это всё фигня по сравнению с мультивыделением. Если мы поддерживаем мультивыделение, нам приходится хранить список выделеных ячеек.


Вот как раз это все фигня. Это всго лишь мап содержащий набор областей выделиния. И это опять же выносится в отдельный интерфейс, а затем в независимые компоненты.

M>Или номеров ячеек? Ага, вот в том и дело, что не всё так просто. Если наш грид отображает некоторую коллекцию, то на что будем равняться: на номер или на объект-элемент?


Естествнно на номе. Коллекции это не его ума дела. Он "виртуал-". И этим все сказано. В ascGrid прекрасно отобразались данные, а базовый грид при этом рботал исключительно с арифметикой.

M>Если мы равняемся на номер, то как быть с удалением элемента из середины? Элементы "поедут" вверх, заполняя "пустоту", а номера выделенных элементов останутся на месте.


Удаление из середины для ВГ не отличается от уменьшения количества строк. Максимум что может произвойти — это понадобится изменить номер первой отображаемой строки. Так что это абстракция из "лексикона" наследников. Просто нужно их как следует уведомить. Сказать, что и где удалено, чтобы им не приходилось делать лишних телодвижений.

Это батенька и есть грамотное абстрагирование о котором я тебе так тщетно пытался говорить.

M>А если равняемся на элемент, то список же может содержать несколько одинаковых объектов в разных позициях.


Опять же не барское это дело в ... ковыряться. Пусть наследник хоть черта лысого хранит. У него будет уже не столько проблем и он сможет со всем как следует разобраться.

M>Наверное, на номер всё-таки лучше равняться. Но отсюда следуют ещё кое-какие следствия. В общем, похоже, как ни крути, а для каждого элемента списка нужно хранить отдельную кешированную структурку с состоянием: IsSelected, RowHeight.


Нет. Не нужно. Проверено на практике. Вернее скжем так. Как опцию нужно хранить кэш размеров строк. Но не для каждой строки, а толко для уже отображашижся. Причем не факт, что реализация этого кэша будет идентична во всх случаях. Для совсем виртальных случаев с миллионами записей которе вряд ли кодгда-нибудь вообще будут орображены все лучше подойдет кэш на базе хэш-таблицы. В более обыйденном случае на базе массива (причем где обычного ArrayList, а где специального двухуровневого, чтобы не тормозила вставка/удаление). Ну, да это уже обсуждалось в наших разговорах с Al-Ko.

AK>>Основные задачи здесь — определение первой видимой строки


M>И сдвига первой строки относительно края. Первая строка может начинаться на три пикселя выше края.


Выше края? Верхнего что ли? А зачем? Да и это приметивнэй офсет. Высчитывание же верхней строки при навигации это несколько более сложный процесс требующий оптимизации.

AK>> вычисление последней видимой строки и оптимальной области, которая должна быть перерисована


M>По идее, нужно идти по элементам и отрисовывать (PaintRow) то тех пор, пока не упрёшься в край. Оптимальную область особо нечего расчитывать, она сама в процессе расчитается.


Именно. Только вот порою придется начинать в середине грида и идти до конца области отрисовки.

M>Опять таки, мультивыделение и FullRowSelect/CellSelect требуют отдельного продумывания.


Это более менее продуманно и относительно не сложно. Но ты прав это как раз нужно сваливать на ВГ. Только не совсе на прямую... ну, да я повтояюсь.

AK>>А контрол-наследник уже сам заботится об отображении этих изменений.


M>Полезно было бы реализовать уже в самом базовом контроле, а наследнику оставить право сделать кастомизацию. В 95% случаев будет использоваться обычная навигация, естественно её внести в базовый класс.


"Заботиться" это и есть "кастомизаци" (в простонародье именуемая настройкой) в твоей терминалогии.

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


M>Я бы ещё советовал виртуальные методы PaintHeader и PaintHeaderCell. Мало ли что там наследники захотят в отрисовке хидера замухлевать.


Тут как раз хорошо подходит твоя идея на счет абстрации строка. Так что сделаем класс HaederRowPainter и один или несколько классов HeaderCellPainter.

AK>> Помимо своего целочисленного индекса, столбцы должны быть именованы


M>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему


Не. Полезно. В конце-концов это ничего не стоит (с точки зрения производительности). Хотя можно и на потом отложить.

Вот что точно нужно сделать и возложить на ВГ, так это абстрогирование номеров колонок от их физического положения. Только вот не факт, что это потять же не стоит вынести в отдельный класс.

M>А также выравнивание текста в соотв. колонках.


Не. Про текст он вообще ничего знат не должен. Это опять таки дело наследников и пэинтеров.

M>А вот склееные столбцы можно с чистой совестью оставить на наследников. Есть стандартный PaintHeaderCell, пусть рисуют хоть склееные, хоть перевёрнутые. Логично?


Согласен. Но мне кажется здесь прекрасно проктывает твоя идея с астрактной строкой. Пусть будет заголовочная-строка которая и будет заниматься склеиванием.

M>Закладываться но текстовые редакторы — это малость маньячеством пахнет. Кто бы не реализовывал редактор, вряд ли ему придёт в голову ивзращаться и наследоваться от грида.


Ошибаешся. Для простых редакторов типа код-эдиторов вроде синтилы или МС-RTF 90% работы это рассчеты по навигации и оптимизация отрисовки. Так что как раз взять подобный контрол за основу — это просто счтай что в четверо упростить проект. Сам понимаешь, это время можно потратить на навороты. Да и работать будет надежнее.

С твоей же идеей абстрагирования строки — это вообще выраждается в стройную концепцию.

M>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.


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

По сути ВГ и есть астрация сролинга. Ну, с небольшими наворотами.

M>P.P.S GetRowHeight должен в базовой реализации возвращать константу. Расчитывать от размера текста дорого.


Да не будет никакой базовой реализации. Зачем она? ВГ будет всегда запрашивать размер строк динамически (через тот самый интерфейс), а уж проблемы наследника какую он подсунет реализацию для ВГ. Захочет посчитает отталкиваясь от размеров текста и картинок. Ан нет вовратит фиксированную величину. Задачи ВГ как можно реже (насколько это возможно) запрашивать подобные данные. Вот и все.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 02.03.04 09:19
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Это всё фигня по сравнению с мультивыделением. Если мы поддерживаем мультивыделение, нам приходится хранить список выделеных ячеек.


M>Или номеров ячеек? Ага, вот в том и дело, что не всё так просто. Если наш грид отображает некоторую коллекцию, то на что будем равняться: на номер или на объект-элемент?


да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей, независимо от того, одну ячейку ты выделяешь, или группу. То есть фактически мы имеем здесь определенным образом устроенную коллекцию из Rectangle. Поскольку ты выделяешь в интерактивном режиме, ничто не мешает упорядочить эту коллекцию так, чтобы поиск того, входит ли очередная отрисовываемая ячейка в область выделения, не занимал много времени.


M>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.


можно не только посмотреть, но и попринимать участие. Так что вэлкам!
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[13]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 02.03.04 09:49
Оценка:
Здравствуйте, mihailik, Вы писали:

AK>> Помимо своего целочисленного индекса, столбцы должны быть именованы


M>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему

а чтобы обращаться к столбцам myGrid.Columns["MyName"]
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
VirtualGrid - фичи
От: Al-Ko  
Дата: 02.03.04 12:01
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Нужно выделить список фич и описать каждую в отдельности. Например:


Перед проектированием остановимся на основных возможностях VirtualGrid и его элементов:
    строки
    столбцы
    полосы прокрутки
    сетка
    выделение (Highlighting)
    фокус и Selection

Строки
     высота
        изменяема в run-time
                  оптимально рассчитывается  для содержимого ячеек
        одинаковая для всех строк
        может быть разной 
    статус в гриде
        пользовательские (обычные, могут вертикально прокручиваться в области изображения)          
        фиксированные (не прокручиваются при вертикальном скроллинге, всегда видны в области изображения)
            строки хидеров
            строки футеров            
        "замороженные пользователем"
    поведение
        могут добавляться/удаляться
        могут перемещаться

Столбцы
    ширина
        изменяема в run-time
                оптимально рассчитывается  для содержимого ячеек
        одинаковая для всех столбцов
        может быть разной
    статус в гриде
        пользовательские (обычные, могут горизонтально прокручиваться в области изображения)          
        фиксированные (не прокручиваются при горизонтальном скроллинге, всегда видны в области изображения)
            левые фиксированные
            правые фиксированные
        "замороженные пользователем"
    поведение
        могут добавляться/удаляться
        могут перемещаться

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

Сетка
    видимость
        не видна
        только горизонтальная
        только вертикальная
        и горизонтальная и вертикальная

Выделение (Highlighting)
    вид
        только строки целиком
        только столбцы целиком
        произвольное выделение ячеек
            только смежных областей
            мультивыделение любых ячеек
    способ
        используя заголовки строк или столбцов
        не используя заголовки

Фокус и Selection
    вид
        только одной ячейки
        строки целиком
        столбца целиком
        и строки и столбца целиком


Просьба добавить/пометить_на_удаление нужное/ненужное. Я потом оформлю все это в виде таблицы


VD>Далее нужно выделить этапы. Ну, там проектирование интерфейсов. Проктирование, фич. Реализация фич: х, у... Причем все это нужно подгадать так, чтобы максимально быстро можно было бы получить рабочий прототип.

после того как утвердим список фич

VD>Так же нужно более четко описать набор контролов-наследников. Возможно даже с указанием тех приемуществ которые они получаят от грида. Это позволит более четко сформулировать необходимые требования.

Я точно вижу здесь:

1) TreeGrid
2) RectangularGrid c возможностью полноценного редактирования ячеек разного типа
3) Spreadsheet c возможностью полноценного редактирования ячеек разного типа, склеивания ячеек — короче а-ля Excel
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[14]: Простой, быстрый, бесплатный грид
От: fddima  
Дата: 02.03.04 12:13
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>можно не только посмотреть, но и попринимать участие. Так что вэлкам!

Самого очень интересует грид... скоро нужен будет, а стандартный как всегда в отстойнике
Лично меня в нем не устраивает, что в Read Only режиме, все клеточки все одно выделяются, Single Row (и соотв.) выделение нормально сделать не выходит. Текст если не влазит в строку форматируется только если стать на ячейку (если высота строки позволяет отобразить)... короче дофига всего не так Так что начинание хорошее А вот собственно сам не думаю что буду полезен...
... << RSDN@Home 1.1.0 stable >>
Re: VirtualGrid - фичи
От: agra  
Дата: 02.03.04 12:27
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Я точно вижу здесь:


AK>2) RectangularGrid c возможностью полноценного редактирования ячеек разного типа


Я правильно понимаю, что это подразумевает собой подстраивание под тип как при отображении, так и при редактировании? Типа bool -> checkbox, enum -> combobox, etc.?
... << RSDN@Home 1.1.3 stable >>
Re[2]: VirtualGrid - фичи
От: Al-Ko  
Дата: 02.03.04 13:08
Оценка:
Здравствуйте, agra, Вы писали:

A>Я правильно понимаю, что это подразумевает собой подстраивание под тип как при отображении, так и при редактировании? Типа bool -> checkbox, enum -> combobox, etc.?

тут не то чтобы подстраивание. Для работы с любым типом данных в гриде нам нужно иметь:

TypeConverter
TypeEditor
TypePainter

Для стандартных типов они будут стандартными, а для пользовательских — нужно будет наследоваться. Нужно сделать так, чтобы в дизайне можно было перетянуть в столбец грида любой контрол из меню Toolbox'а, и грид мог с ним работать в рантайме либо без дополнительных телодвижений, либо с помощью наследников этих классов.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[15]: Простой, быстрый, бесплатный грид
От: SiAVoL Россия  
Дата: 02.03.04 13:15
Оценка:
Здравствуйте, fddima, Вы писали:

F>Лично меня в нем не устраивает, что в Read Only режиме, все клеточки все одно выделяются, Single Row (и соотв.) выделение нормально сделать не выходит. Текст если не влазит в строку форматируется только если стать на ячейку (если высота строки позволяет отобразить)... короче дофига всего не так

Ну это все можно и в стандартном гриде сделать через своих наследников System.Windows.Forms.DataGridColumnStyle
Но мы все-равно сделаем лучше
... << RSDN@Home 1.1.3 stable >>
Re[3]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 15:37
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>TypeConverter

AK>TypeEditor
AK>TypePainter

Зачем Type? Одни и те же типы данных можно отобразать по разному.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: VirtualGrid - фичи
От: Al-Ko  
Дата: 02.03.04 15:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Al-Ko, Вы писали:


AK>>TypeConverter

AK>>TypeEditor
AK>>TypePainter

VD>Зачем Type? Одни и те же типы данных можно отобразать по разному.

вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[14]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 02.03.04 16:22
Оценка:
M>>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему
AK>а чтобы обращаться к столбцам myGrid.Columns["MyName"]

А какая в этом бывает необходимость?
... << RSDN@Home 1.1.3 stable >>
Re[14]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 02.03.04 16:22
Оценка:
AK>да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей

Я имею в виду не сам процесс выделения, а хранение списка выделенных ячеек.

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

M>>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.


AK>можно не только посмотреть, но и попринимать участие. Так что вэлкам!


Будем посмотреть. Пока вот разве что мысли подкинуть могу, времени маловато
... << RSDN@Home 1.1.3 stable >>
Re[14]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 02.03.04 16:22
Оценка:
VD>Но этот объкт должен очень тесно интегрироваться с ВГ, так как не мловажны такие вещи как оптимизация отрисовки ячеек (их может быть много а перерисовать нужно всего пару-тройку).

В PaintRow, очевидно, стоит передавать ClipRectangle — регион, который требуется порисовать. Соответственно, сам PaintRow выберет, какие ячейки рисовать, какие оставить в покое. Гуд?

M>>Для этого из PaintCell вызывается GetCellText.


VD>Тлько PaintCell это не метод, а класс. Он кстати должен заниматься нехилым кэшированием. Он может хранить строки формата, информацию о шрифте, браши и т.п.


Ну, не знаю. А зачем воротить отдельный класс? Это лишний уровень абстракции, под который нет задач. Люди всё равно будут наследовать весь грид, так пусть сразу и переопределяют методы PaintRow, PaintCell. Создавать лишние классы — это ещё оверхед и в рантайме и в написании кода.

Впрочем, вам, разработчикам, виднее.


VD>А вот тут не согласен. Стандартных реализаций ненужно вообще. Будут просто реализации. Для текста, для дат, для целых, для денег, для флоата, для картинок, ... Причем все они должны поддерживать стили, чтобы можно было менять множество параметров множества колонок и гридов одним махом.


Стили на уровне чего? Как это, стили?

VD>Причем офигительной крутости можно достигнуть если можно будет менять его "налету", т.е. при отрисовки разных ячеех (строк) одной и той же колонки можно махать пэинтер в зависимости от условий. Это позволит делать так называмые вертикальные гриды и вообще разнообразить отрисовку.


В 99% случаев людям нужно задать шрифт, иконку и строку формата. Это реализуется значительно проще, чем выделенные пэйнтеры. Насколько функциональность пэйнтеров важна, чтобы реализовывать её в базовом классе? Не лучше ли в базовом классе обойтись максимально быстрыми виртуальными методами, а пэйнтеры добавлять в потомке?

VD>Скорость такой замены очень высокая (это же всего лишь ссылка). И очень хорошо экономятся ресурсы, так как вариантов отисовки в реальном риложении не так уж много.


Объективно по сравнению с виртуальными методами это оверхед по всем статьям. Может оно где-то и лучше, но не в вопросе ресурсов/скорости.

M>>Вот мне не понятно, почему с наследником общаться через интерфейс? Для этого есть виртуальные функции. Зачем систему усложнять


VD>Потму что не факт, что общаться будет сам наследник. Я могу подснуть вемето него все что угодно. Причем динамически.


Я бы лучше понял на примере. Моя позиция такая. Гридовыми задачами: отрисовкой, навигацией etc. должен заниматься сам грид. Если приложение начинает слишком плотно с ним общаться, это плохо. Пусть приложение поставляет данные, указывает опции, но не копается во внутренностях реализации.

Можно наследнику реализовать интерфейсы, внутренние классы-пайнтеры. Но тогда возникает естественный вопрос, зачем этот лишний уровень абстракции?


VD>Вот как раз это все фигня. Это всго лишь мап содержащий набор областей выделиния. И это опять же выносится в отдельный интерфейс, а затем в независимые компоненты.


Как сихронизировать этот мап с изменениями коллекции?


M>>Если мы равняемся на номер, то как быть с удалением элемента из середины? Элементы "поедут" вверх, заполняя "пустоту", а номера выделенных элементов останутся на месте.


VD>Удаление из середины для ВГ не отличается от уменьшения количества строк.


Пример:

  Сыр
* Колбаса
  Картошка
* Молоко
  Творог


Выделенное помечено. Теперь вдруг из коллекции удаляют Картошку. Получается:

  Сыр
* Колбаса
  Молоко
* Творог


Молоко перестало быть выделеным, а творог стал! Это не очень-то правильно. Да?

VD>Просто нужно их как следует уведомить. Сказать, что и где удалено, чтобы им не приходилось делать лишних телодвижений.


А как это? Удаление ведь произошло из коллекции, а ICollection нотификаций не шлёт.

VD>Нет. Не нужно. Проверено на практике. Вернее скжем так. Как опцию нужно хранить кэш размеров строк. Но не для каждой строки, а толко для уже отображашижся.


А как тогда узнать общий размер всего списка?

AK>>>Основные задачи здесь — определение первой видимой строки


M>>И сдвига первой строки относительно края. Первая строка может начинаться на три пикселя выше края.


VD>Выше края? Верхнего что ли? А зачем? Да и это приметивнэй офсет.


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


VD>Именно. Только вот порою придется начинать в середине грида и идти до конца области отрисовки.


Это всё понятно. Вот и выходит: номер верхней видимой строки и ещё её микроскопический офсет, "задвиг".


AK>>> Помимо своего целочисленного индекса, столбцы должны быть именованы


M>>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему


VD>Не. Полезно. В конце-концов это ничего не стоит (с точки зрения производительности). Хотя можно и на потом отложить.


Фиг его знает

VD>Вот что точно нужно сделать и возложить на ВГ, так это абстрогирование номеров колонок от их физического положения. Только вот не факт, что это потять же не стоит вынести в отдельный класс.


Чтобы он его виртуально "тусовал" в рантайме? Странно это

M>>А также выравнивание текста в соотв. колонках.


VD>Не. Про текст он вообще ничего знат не должен. Это опять таки дело наследников и пэинтеров.


Ну, я имею ввиду вообще выравнивание. Вроде бы логичное свойство как для изображений так и для текста или чего угодно. Причём выравнивание правильно делать девятипозиционным: по углам, по сторонам и по центру.

А пайнтеры или кто там будет этим заниматься, уж пусть принимают к сведению эти алигны.


M>>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.


VD>Радует уже тот факт, что мы заинтересовали такого велосипедиста как ты. Ведь я месяца два пытался обяснить что писать тригриды влоб тяжело и бессмысленно.


Да я давно поглядываю интересуюсь, но пока не готов участвовать в кодировании или принятии каких-то решений. Вы-то молодцы, а я хочу вот на Kiev .NET User Group как следует заманьячиться, много времени уходит.


Ну и ложка дёгтя для укрепления иммунитета.

В .NET 1.2 навернули новый грид, и актуальность этого виртуального проекта может уменьшиться. Вообще, они там даже два новых грида навернули: GridView и Table. Но Table, похоже, не жилец, какая-то левая ветка разработки. Исключат его из релиза, помяните моё слово. А GridView, наоборот, собираются ещё дорабатывать.

Кроме того, ListView усовершенствовали. Точно помню, что там есть OwnerDraw. И, кажется, виртуальность тоже появилась.

Скоро бета, а там и релиз. Обстановка для гридописательства накаляется.
... << RSDN@Home 1.1.3 stable >>
Re[15]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, mihailik, Вы писали:

AK>>да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей


M>Я имею в виду не сам процесс выделения, а хранение списка выделенных ячеек.

я тоже. Храни их в виде списков прямоугольников областей выделения, например:

Rectangle1 (строка 2, столбец 0, строка 5, столбец 17)
Rectangle2 (строка 6, столбец 5, строка 6, столбец 5)
Rectangle3 (строка 0, столбец 7, строка 200, столбец 7)

рассортируй эти ректанглы как тебе удобно, и проверяй, входит ли твоя ячейка в область выделения

M>Или ты хочешь хранить список выделенных прямоугольников, а не ячеек? Это что-то остроумное, но подозрительное. Пользователю будет непривычно, наверное.

а что пользователю? Он будет иметь два метода: IsCellHighlighted и HighlightCells(те же четыре координаты)

M>Внутри одна ячейка удалилась, и выделенные прямоугольники остались на месте?

во-первых, объясни, как это: одна ячейка удалилась? Удалиться может только строка или столбец. В этом случае можно скорректировать коллекцию ректанглов. А во-вторых, в большинстве случаев удаления подсветка либо убирается вообще (в гриде) или остается на том же месте (в спредшите).

M>Будем посмотреть. Пока вот разве что мысли подкинуть могу, времени маловато

мысли — это самое ценное и есть
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[15]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 02.03.04 17:19
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему

AK>>а чтобы обращаться к столбцам myGrid.Columns["MyName"]

M>А какая в этом бывает необходимость?

ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...
и все дела. Удобно?
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[16]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 02.03.04 17:29
Оценка:
M>>Внутри одна ячейка удалилась, и выделенные прямоугольники остались на месте?
AK>во-первых, объясни, как это: одна ячейка удалилась? Удалиться может только строка или столбец.

Да, строка. Типа, обновили Refresh, и там больше этой позиции нету.

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


Да, похоже, что ты прав. Надо подумать, всё-таки этот подход мне внутри коробит.
... << RSDN@Home 1.1.3 stable >>
Re[16]: Простой, быстрый, бесплатный грид
От: mihailik Украина  
Дата: 02.03.04 17:40
Оценка:
AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...
AK>и все дела. Удобно?

Не очень. Мало ли, ошибёшься вместо "Totals" напишешь "Total". Удобно так: totalsColumnHeader.BackColor=...

То есть наследовать ColumnHeader от Component и пусть он будет полноправным компонентом с полем в DesignTime.
... << RSDN@Home 1.1.3 stable >>
Re[17]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 02.03.04 17:59
Оценка:
Здравствуйте, mihailik, Вы писали:

AK>>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...

AK>>и все дела. Удобно?

M>Не очень. Мало ли, ошибёшься вместо "Totals" напишешь "Total". Удобно так: totalsColumnHeader.BackColor=...

M>То есть наследовать ColumnHeader от Component и пусть он будет полноправным компонентом с полем в DesignTime.
можно и так. А может быть, и нужно. Будем обсуждать. В конце концов, стили столбцов в датагриде устроены именно так.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[5]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 18:04
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.


Под "дизайнером" ты имешь в виду проперти-грид?

Ну, тут скажем так не все грамотно. Многое сложно (та же кастом-отрисовка сделана очень сложно и криво). Хотя идея с UIEditor-ом в принципе правильная. Только опять таки неполноценная.

В общем, я бы взял лучшее, но ориентировался бы на собственную реализацию. Как вариант универсальный эдитор позволяющий использовать дотнетные средства.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 18:04
Оценка:
Здравствуйте, mihailik, Вы писали:

M>В PaintRow, очевидно, стоит передавать ClipRectangle — регион, который требуется порисовать. Соответственно, сам PaintRow выберет, какие ячейки рисовать, какие оставить в покое. Гуд?


ОК

VD>>Тлько PaintCell это не метод, а класс. Он кстати должен заниматься нехилым кэшированием. Он может хранить строки формата, информацию о шрифте, браши и т.п.


M>Ну, не знаю. А зачем воротить отдельный класс?


См. выделенное. К тому же это позволит очень легко заменять реализацию. В аскДБ мы заменяли реализацию прямо перед отрисовкой строки. Это позволяло сделать отрисовку невоятно гибкой.

M> Это лишний уровень абстракции, под который нет задач. Люди всё равно будут наследовать весь грид, так пусть сразу и переопределяют методы PaintRow, PaintCell. Создавать лишние классы — это ещё оверхед и в рантайме и в написании кода.


Это плохой подход. Почему? Я уже говорил и не раз.

M>Впрочем, вам, разработчикам, виднее.


Более того уже опробовано. Да и в самом дотнете очень похожие решения.

M>Стили на уровне чего? Как это, стили?


Некий объект содержащий стандартный набор свойств вроде фона, цветов и т.п. У пэинтеров, редакторо и сам грид будет свойство Style. Присваиваешь ему этот объект и он начинает использовать эти данные.

M>В 99% случаев людям нужно задать шрифт, иконку и строку формата.


И? Есть проблемы?

M> Это реализуется значительно проще, чем выделенные пэйнтеры.


А зачем проще? Одно поглащает другое.

M> Насколько функциональность пэйнтеров важна, чтобы реализовывать её в базовом классе?


Она не реализуется ни в базовом классе (он же ВГ), ни в наследниках. Это отдельные классы. И их можно менять на ходу.

M> Не лучше ли в базовом классе обойтись максимально быстрыми виртуальными методами, а пэйнтеры добавлять в потомке?


Нет. Не лучше. Лучше в ВГ вообще не заниматься отрисовкой. ВГ расчитывает область отрисовки, высчитывает строки которые нужно перерисовать, вызывает интерфейс отрисовки, а остально делает он.

M>Объективно по сравнению с виртуальными методами это оверхед по всем статьям. Может оно где-то и лучше, но не в вопросе ресурсов/скорости.


Это и будет в конечном итоге вызом метода интерфейса. Просто вызов будет не у наследника, а у отдельной ссылки которая задается при инициализации или динамически (на событие). Оверхэд равен нулю. Саксимальное количество ячеек отрисовываемых одновременно будет гдето 1000-2000. Две тысячи вызовов — это НОЛЬ!

M>Я бы лучше понял на примере. Моя позиция такая. Гридовыми задачами: отрисовкой, навигацией etc. должен заниматься сам грид.


Значит теб с нами не по пути. Мое мнение, ВГ вообще не должен заниматься непосредственно отрисовкой, да и его наследники тоже. Это отдельная задача и ее нажно отделять. Это и упростит реализацию и добавит гибкости.

M> Если приложение начинает слишком плотно с ним общаться, это плохо. Пусть приложение поставляет данные, указывает опции, но не копается во внутренностях реализации.


Бывают разные ситуации. Где-то так, где-то нужна более гибкая реализация.

M>Можно наследнику реализовать интерфейсы, внутренние классы-пайнтеры. Но тогда возникает естественный вопрос, зачем этот лишний уровень абстракции?


Наследник не реализует пэинтеры и редакторы. Он только подключает те реализации которые ему нужны по его логике.

M>Как сихронизировать этот мап с изменениями коллекции?


На колбэках. Там всего то что может быть — это удаление/вставка колонок и строк. В общем, набор ифов.

M>Молоко перестало быть выделеным, а творог стал!


Почему?

M> Это не очень-то правильно. Да?


Зависит от логики. Но для ВГ выделение это всего лишь набор флагов.

M>А как это? Удаление ведь произошло из коллекции, а ICollection нотификаций не шлёт.


Это твои проблемы. Грид ничего не удалит пока ты егму это не прикажешь (вызовешь метод).

У меня в ТриГрид2 коллекция обязана уведомлять грид при удалении. Быапют дркгие парадигмы.

M>А как тогда узнать общий размер всего списка?


Спросить у наследника. Хранение размеров это не задача ВГ.

M>Ну да, и его тоже нужно не забыть, я это имел ввиду. Верхняя строка может отображаться не полностью, а чуть "задвинутой" за край таблицы. Ну, если скролл делать не дискретным, а полноценный smooth.


Да жаже если дискретным. Последня строка может показываться не циликом. Только это ничего ровным счетом не меняет. Она тоже видимая. Вот при клике мыши или при активизации это нужно учитывать...

M>Это всё понятно. Вот и выходит: номер верхней видимой строки и ещё её микроскопический офсет, "задвиг".


Какой сдвиг? Ну, да ладно. Если ячейка видна не полностью, ей все равно придется отрисоваться. Просто клип-рект ей дадут не раный ее размеру. Это все такие мелочи.

VD>>Не. Полезно. В конце-концов это ничего не стоит (с точки зрения производительности). Хотя можно и на потом отложить.


M>Фиг его знает


Точно. Сам грид работает с колонками по индексу. Имена нужны для прикладника. Причем он тоже может получить ссылку на колонки у дальше работать напрямую.

VD>>Вот что точно нужно сделать и возложить на ВГ, так это абстрогирование номеров колонок от их физического положения. Только вот не факт, что это потять же не стоит вынести в отдельный класс.


M>Чтобы он его виртуально "тусовал" в рантайме? Странно это


Кого тусовал? Что странно? Ты в эксплорере колонки перемещал когда-нибудь? Думаешь индекс колонки изменяется от этого? Я об этом.

M>Ну, я имею ввиду вообще выравнивание. Вроде бы логичное свойство как для изображений так и для текста или чего угодно. Причём выравнивание правильно делать девятипозиционным: по углам, по сторонам и по центру.


ВГ не отображает ничего сам. Это не его забота.

M>А пайнтеры или кто там будет этим заниматься, уж пусть принимают к сведению эти алигны.


Вот они и будут брать эти данные из источников вроде тип выводимых данных, стили, свойства колонок...

M>Да я давно поглядываю интересуюсь, но пока не готов участвовать в кодировании или принятии каких-то решений. Вы-то молодцы, а я хочу вот на Kiev .NET User Group как следует заманьячиться, много времени уходит.


А на легкое написание собственных ТриГридов, значит, времени хватает.

M>В .NET 1.2 навернули новый грид, и актуальность этого виртуального проекта может уменьшиться. Вообще, они там даже два новых грида навернули: GridView и Table. Но Table, похоже, не жилец, какая-то левая ветка разработки. Исключат его из релиза, помяните моё слово. А GridView, наоборот, собираются ещё дорабатывать.


M>Кроме того, ListView усовершенствовали. Точно помню, что там есть OwnerDraw. И, кажется, виртуальность тоже появилась.


M>Скоро бета, а там и релиз. Обстановка для гридописательства накаляется.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Простой, быстрый, бесплатный грид
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 07:46
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...

AK>и все дела. Удобно?

Фигово. Прикинь что будет если понадобится локализация.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[17]: Простой, быстрый, бесплатный грид
От: Воронков Василий Россия  
Дата: 03.03.04 07:53
Оценка:
"AndrewVK" <5161@news.rsdn.ru> wrote in message news:557631@news.rsdn.ru...
> Здравствуйте, Al-Ko, Вы писали:
>
> AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...
> AK>и все дела. Удобно?
>
> Фигово. Прикинь что будет если понадобится локализация.

myGrid.Columns[StringManager.GetString("Totals")].BackColor = ...

Posted via RSDN NNTP Server 1.8 beta
Re: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 03.03.04 08:32
Оценка: 10 (1)
Здравствуйте, Al-Ko, Вы писали:

AK>
AK>Строки
AK>     высота
AK>        изменяема в run-time
AK>                  оптимально рассчитывается  для содержимого ячеек
AK>        одинаковая для всех строк
AK>        может быть разной
Что то я не совсем понял такое разбиение... Мне думается есть всего два варианта:
[list]
[*] Изменяемая высота
[*] Постоянная высота
[/list]
В случае изменяемой может быть два варианта: 
    - наследник передает ВГ (виртуальный грид) высоты строк и ВГ на эти высоты никак повлиять не может.
    - ВГ опять же получает высоты от наследника, но пользователь может изменять высоту строки через ВГ (мышкой), в этом случае ВГ уведомляет наследника об этих изменениях

AK>Сетка
Выделение этого пункта мне кажется лишним. Сетка - это проблемы наследника, имхо.

AK>Выделение (Highlighting)
Это тоже сложный вопрос. Предлагаю сначала разобраться с тем, кто за что отвечает (где обязанности ВГ, а где наследника)
Я так понимаю, что строка вполне может принять такой вид
[code]
*********************************
*   *    2       *      3       *
* 1 *****************************
*   *   4   *        5          *
*********************************

Причем сам ВГ об этих сцеплениях (а не исключены и большие извращения ) представления не имеет. Таким образом возникает вопрос: как ВГ будет рисовать сетки и выделять ячейки? Если же ВГ будет знать обо всем этом, то мы потеряем в гибкости и заложим ВГ лишний функционал, который должен быть вынесен отдельно.
Вот что я думаю о ВГ:

В общем надо думать...
... << RSDN@Home 1.1.3 stable >>
Re[6]: VirtualGrid - фичи
От: Al-Ko  
Дата: 03.03.04 10:23
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Al-Ko, Вы писали:


AK>>вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.


VD>Под "дизайнером" ты имешь в виду проперти-грид?

ну да

VD>В общем, я бы взял лучшее, но ориентировался бы на собственную реализацию. Как вариант универсальный эдитор позволяющий использовать дотнетные средства.

согласен
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[16]: Простой, быстрый, бесплатный грид
От: fddima  
Дата: 03.03.04 11:20
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Ну это все можно и в стандартном гриде сделать через своих наследников System.Windows.Forms.DataGridColumnStyle

SAV>Но мы все-равно сделаем лучше
Та я в принципе в курсе, просто не успел еще Функциональность важнее отображения типа... В общем болею всем телом за ваше "лучше"! Спасибо
... << RSDN@Home 1.1.0 stable >>
Re[17]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 03.03.04 13:19
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AK>>Но я пишу myGrid.Columns["Totals"].BackColor = ...


AVK>Фигово. Прикинь что будет если понадобится локализация.

а при чем здесь локализация? Это всего лишь внутренний индекс для обращения к конкретному столбцу. Не целочисленный, а строковый.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[2]: VirtualGrid - фичи
От: Al-Ko  
Дата: 03.03.04 14:39
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Здравствуйте, Al-Ko, Вы писали:


AK>>
AK>>Строки
AK>>     высота
AK>>        изменяема в run-time
AK>>                  оптимально рассчитывается  для содержимого ячеек
AK>>        одинаковая для всех строк
AK>>        может быть разной
AK>>

SAV>Что то я не совсем понял такое разбиение... Мне думается есть всего два варианта:
SAV> SAV>В случае изменяемой может быть два варианта:
SAV> — наследник передает ВГ (виртуальный грид) высоты строк и ВГ на эти высоты никак повлиять не может.
SAV> — ВГ опять же получает высоты от наследника, но пользователь может изменять высоту строки через ВГ (мышкой), в этом случае ВГ уведомляет наследника об этих изменениях
я здесь хотел акцентировать внимание, что высота, независимо от того изменяема ли она, или постоянна, может быть одинаковой для всех строк, а может быть разной. В том случае, если она одинакова для всех строк, нам не нужно включать многие механизмы виртуал грида. Т.е. просто описан частный (и довольно частый) случай, который можно задавать в настройках (IMHO, конечно).
AK>>Сетка
SAV>Выделение этого пункта мне кажется лишним. Сетка — это проблемы наследника, имхо.
я думал, что проблема наследника — это нарисовать сетку. Проблема ВГ состоит в том, чтобы дать наследнику команду на ее рисование. Чтобы дать команду, нужно знать настройки для сетки. Наличие или отсутсвие сетки — это как бы общая часть всех гридов. Отрисовка сетки — это вопрос наследника.


AK>>Выделение (Highlighting)

SAV>Это тоже сложный вопрос. Предлагаю сначала разобраться с тем, кто за что отвечает (где обязанности ВГ, а где наследника)
SAV>Я так понимаю, что строка вполне может принять такой вид
SAV>
SAV>*********************************
SAV>*   *    2       *      3       *
SAV>* 1 *****************************
SAV>*   *   4   *        5          *
SAV>*********************************
SAV>

SAV>Причем сам ВГ об этих сцеплениях (а не исключены и большие извращения ) представления не имеет. Таким образом возникает вопрос: как ВГ будет рисовать сетки и выделять ячейки? Если же ВГ будет знать обо всем этом, то мы потеряем в гибкости и заложим ВГ лишний функционал, который должен быть вынесен отдельно.
в этом случае сетка рисуется после отрисовки очередной ячейки. ВГ после обработки отрисовки ячейки смотрит, есть ли у него вертикальная сетка. Если есть, он говорит наследнику — рисуй ее. После того, как все ячейки в строке отрисованы, он проделывает тоже самое с горизонтальной сеткой. Что касается выделения, то попробуй смоделировать нарисованную тобой ситуацию в Excel и посмотри, как там просто все решается.


SAV>Вот что я думаю о ВГ:

SAV>
абсолютно согласен.

SAV>В общем надо думать...
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[17]: Простой, быстрый, бесплатный грид
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 18:26
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Фигово. Прикинь что будет если понадобится локализация.


Чего? Внутренней реализации? Может еще и код локализуем?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: VirtualGrid - фичи
От: Al-Ko  
Дата: 05.03.04 12:03
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Здравствуйте, VladD2, Вы писали:


AK>Перед проектированием остановимся на основных возможностях VirtualGrid и его элементов:


че-то у нас обсуждение как-то заглохло. Влад, что делаем дальше?
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[2]: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 05.03.04 12:13
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>че-то у нас обсуждение как-то заглохло.

праздники . Я вот на выходных че-нить попробую осмылить и изложить
AK>Влад, что делаем дальше?
Мне кажется следующим пунктом должно быть выделение основных абстракций с из обязанностями и, возможно, примерным интерфейсом. Главное щас четко разделить обязанности между абстракциями и определить между ними связи
... << RSDN@Home 1.1.3 stable >>
Re[2]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.04 22:22
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>че-то у нас обсуждение как-то заглохло. Влад, что делаем дальше?


По-моему давно пора переходить к проектированию интерфейсов и пребным реализациям.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 11.03.04 11:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>По-моему давно пора переходить к проектированию интерфейсов и пребным реализациям.

угу, согласен. Я вот и собирался к этому перейти на прошлых выходных, но праздники спутали все планы. А сейчас у меня неделя запарочная. Так что я только с понедельника
... << RSDN@Home 1.1.3 stable >>
Re: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 17.03.04 08:01
Оценка:
Пожалуй пора продолжить . Я тут приведу некие наброски аля первые мысли...
Итак, проведем инвентаризацию, что у нас имеется :
1. абстрактный VirtualGrid — связывает в единый механизм все остальные абстракции. Сам по себе умеет очень мало.
    public abstract class VirtualGrid : Control
    {
        public VirtualGrid() {}

        private bool _RowsHeightConst = true;
        public bool RowsHeightConst
        {
            get { return _RowsHeightConst; }
            set { _RowsHeightConst = value; }
        }

        private bool _ColumnsHeightConst = false;
        public bool ColumnsHeightConst
        {
            get { return _ColumnsHeightConst; }
            set { _ColumnsHeightConst = value; }
        }

        private VGColumnCollection _Columns = new VGColumnCollection();
        public VGColumnCollection Columns
        {
            get { return _Columns; }
            set { _Columns = value; }
        }

        private IVGDataSource _DataSource = null;
        public IVGDataSource DataSource
        {
            get { return _DataSource; }
            set { _DataSource = value; }
        }
    
        private VGHorScroller _HorScroller;
        public HorScroller HorScroller
        {
            get { return _HorScroller; }
            set { _HorScroller = value; }
        }

        private VGVertScroller _VertScroller;
        public VGVertScroller VertScroller
        {
            get { return _VertScroller; }
            set { _VertScroller = value; }
        }
    
    }

2. Интерфейс источника данных IVGDataSource — знает количество строк, предоставляет по запросу данные.
    public interface IVGDataSource
    {
        int RowsCount { get; }
        object GetData(int Row);
        event EventHandler DataChanged;
    }

3. Колонка VGColumn и коллекция колонок VGColumnCollection
    public class VGColumn
    {
        public VGColumn()
        {
        }

        private string _Name;
        public string Name
        {
            get {return _Name; }
            set { _Name = value; }
        }

        private string _Title;
        public string Title
        {
            get { return _Title; }
            set { _Title = value; }
        }
    }
    
    public class VGColumnCollection : CollectionBase
    {
        public VGColumnCollection()
        {
        }

        public VGColumn this[int index]
        {
            get { return (VGColumn)List[index]; }
            set { List[index] = value; }                                        
        }

        public VGColumn this[string Name]
        {
            get { return null; }
            set { }
        }
    }

4. Строка VGRow и коллекция строк VGRowCollection (на сколько я понимаю, наш грид полностью симметричен относительно колонок/строк)
5. Скроллеры. Имеется некий абстрактный класс скроллеров, вертикальный и горизонтальный скроллеры наследуются от него
    public abstract class VGScroller
    {
        public VGScroller()
        {
        }

        protected int _MaxSize;
        public int MaxSize
        {
            get { return _MaxSize; }
            set { _MaxSize = value; }
        }

        protected int _MinSize;
        public int MinSize
        {
            get { return _MinSize; }
            set { _MinSize = value; }
        }

        protected int _Value;
        public int Value
        {
            get { return _Value; }
            set
            {
                _Value = value;
                OnValueChanged();
            }
        }

        public event EventHandler ValueChanged;
        protected void OnValueChanged()
        {
            if (ValueChanged != null)
                ValueChanged(this, new EventArgs());
        }
    }

public class VGGorScroller : VGScroller { /*...*/ }
public class VGVerScroller : VGScroller { /*...*/ }

6. Некая абстракция для управления фокусом и выделением...
... << RSDN@Home 1.1.3 stable >>
Re[2]: VirtualGrid - фичи
От: Al-Ko  
Дата: 19.03.04 13:00
Оценка:
Здравствуйте, SiAVoL, Вы писали:

ok, давай поэтапно.

SAV> public abstract class VirtualGrid : Control

SAV> {
1. От чего насследуется VirtualGrid.
Если мы наследуемся от Control'а, то нам для обеспечения скроллинга нужно будет создавать свои контролы скроллбаров и лепить их к краям контрола.
Преимущества такого подхода: не нужно лезть в WndProc и ловить WM_xSCROLL сообщения для окна, а обрабатывать только события Scroll этих скроллбаров. Недостатки: скроллбары будут находиться в клиентской области окна, поэтому придется каждый раз при вычислениях это учитывать; при одновременном появлении двух скроллбаров нужно лепить в правый нижний угол квадратик-панельку, для того, чтобы там не было дырки .
Если наследоваться от ScrollableControl или его наследников, то таких проблем не будет, но нужно будет работать с сообщениями окна.
Короче, вроде как мы с Владом определились отталкиваться от второго варианта. Только надо вынести Scroller в отдельный класс, который потом можно будет заменить или изменить.

2. Интерфейс IVirtualGrid.

Пока остановимся на этом:

    interface IVirtualGrid
    {
        int RowsCount
        {
            get;
            set;
        }

        int TopRow
        {
            get;
            set;
        }

        bool CacheRowsHeight
        {
            get;
            set;
        }

        int GetBottomRow();

    }


к этому интерфейсу будет обращаться грид-наследник.

Дальше. Это частный случай, если строки и столбцы имеют неизменные размеры, это ОК:

SAV> private bool _RowsHeightConst = true;

SAV> private bool _ColumnsHeightConst = false;

это здесь не нужно:

SAV> private IVGDataSource _DataSource = null;

SAV> public IVGDataSource DataSource
SAV> {
SAV> get { return _DataSource; }
SAV> set { _DataSource = value; }
SAV> }

скроллеры пока убираем:
SAV> private VGHorScroller _HorScroller;
SAV> }


ага, это ты пытался делать нечто вроде интерфейса IVirtualGrid.

SAV>[/c#]

SAV>2. Интерфейс источника данных IVGDataSource — знает количество строк, предоставляет по запросу данные.
SAV>
SAV>    public interface IVGDataSource
SAV>    {
SAV>        int RowsCount { get; }
SAV>        object GetData(int Row);
SAV>        event EventHandler DataChanged;
SAV>    }
SAV>


Это не нужно, с данными работает наследник VirtualGrid.

3. Теперь о столбцах и их коллекции.

Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.
После этого нужно двигаться дальше.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[3]: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 19.03.04 13:20
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Если наследоваться от ScrollableControl или его наследников, то таких проблем не будет, но нужно будет работать с сообщениями окна.

AK>Короче, вроде как мы с Владом определились отталкиваться от второго варианта. Только надо вынести Scroller в отдельный класс, который потом можно будет заменить или изменить.
Да я вроде тоже собирался его от ScrollableControl унаследовать, запарил

AK>это здесь не нужно:

возможно...

AK>Это не нужно, с данными работает наследник VirtualGrid.

может быть имеет смысл общие методы работы с данными вынести в VirtualGrid? что бы можно было унифицированно работать с разными гридами

AK>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.

Я большого смысла в этом не вижу

AK>После этого нужно двигаться дальше.

двигаемся дальше
... << RSDN@Home 1.1.3 stable >>
Re[3]: VirtualGrid - фичи
От: orangy Россия
Дата: 19.03.04 13:27
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Если мы наследуемся от Control'а, то нам для обеспечения скроллинга нужно будет создавать свои контролы скроллбаров и лепить их к краям контрола.

Так и придётся делать.

AK>Если наследоваться от ScrollableControl или его наследников, то таких проблем не будет, но нужно будет работать с сообщениями окна.

Так не получится. Как только у тебя появятся хидеры колонок, ты поимеешь кучу проблем с ScrollableControl, не говоря уж о тех проблемах, которые в нём есть от рождения — очень уж плохо управляется там скроллингом... Я пробовал и так и эдак, и через интероп — складывать скроллеры как внутренние контролы всяко удобнее.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[3]: VirtualGrid - фичи
От: orangy Россия
Дата: 19.03.04 13:33
Оценка: 5 (1)
Здравствуйте, Al-Ko, Вы писали:

AK>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.

Делать. Если у колонки появятся всякие события, например, HeaderRightClick, Sort или еще чего — тебе будет сложновато подписаться на эти события из дизайнера — придётся писать свой хитрый редактор коллекции с подпиской на сообщения, ну или делать это из кода. Кроме того, всё таки
// удобнее писать 
clmName.ForeColor = Color.Red;
// чем 
grid.Columns["Name"].ForeColor = Color.Red;

Только не забыть поставить [DesignTimeVisible(false)], чтобы в Component Tray они не болтались почём зря.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[4]: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 19.03.04 13:43
Оценка:
Здравствуйте, orangy, Вы писали:

O>Здравствуйте, Al-Ko, Вы писали:


AK>>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.

O>Делать.
А получится ли нормально DataGridColumnStyle воткнуть в наш грид? чет я не думаю. хотя у меня уже щас сображалка плохо втыкает, надо завтра подумать
... << RSDN@Home 1.1.3 stable >>
Re[5]: VirtualGrid - фичи
От: orangy Россия
Дата: 19.03.04 13:47
Оценка:
Здравствуйте, SiAVoL, Вы писали:

AK>>>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.

O>>Делать.
SAV>А получится ли нормально DataGridColumnStyle воткнуть в наш грид? чет я не думаю. хотя у меня уже щас сображалка плохо втыкает, надо завтра подумать
Нет, ну прямо DataGridColumnStyle не надо втыкать, там интерналы есть. Надо свой класс колонки написать. Согласно архитектуре.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[5]: VirtualGrid - фичи
От: SiAVoL Россия  
Дата: 19.03.04 13:49
Оценка:
AK>>>Надо решить, делать ли Column компонентом (его наследником)
тьфу, блин. Прочитал неправильно Компонентом надо делать
SAV>щас сображалка плохо втыкает
все, пора уходить в плановый запой — расслабляться (за подробностями сюда
Автор: SiAVoL
Дата: 18.03.04
)
... << RSDN@Home 1.1.3 stable >>
Re[4]: VirtualGrid - ScrollableControl
От: Al-Ko  
Дата: 19.03.04 14:07
Оценка:
Здравствуйте, orangy, Вы писали:

O
O>Так не получится. Как только у тебя появятся хидеры колонок, ты поимеешь кучу проблем с ScrollableControl, не говоря уж о тех проблемах, которые в нём есть от рождения — очень уж плохо управляется там скроллингом... Я пробовал и так и эдак, и через интероп — складывать скроллеры как внутренние контролы всяко удобнее.

ScrollableControl нужен только для того, чтобы обеспечить наличие скроллбаров в клиентской области и также генерирования сообщений скроллинга для окна. После этого весь его ненавязчивый сервис надо попытаться отключить. Технологией с отдельными скроллбарами-контролами я владею, а вот хотелось бы попробовать именно с сабжем. А что, есть печальный опыт, который говорит что это не получится?
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[4]: VirtualGrid - фичи
От: Al-Ko  
Дата: 19.03.04 14:11
Оценка:
Здравствуйте, orangy, Вы писали:
O>Делать. Если у колонки появятся всякие события, например, HeaderRightClick, Sort или еще чего — тебе будет сложновато подписаться на эти события из дизайнера — придётся писать свой хитрый редактор коллекции с подпиской на сообщения, ну или делать это из кода. Кроме того, всё таки
O>[c#]
O>// удобнее писать
O>clmName.ForeColor = Color.Red;

вот очень лежит душа именно так и сделать
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[5]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 20.03.04 12:52
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>ScrollableControl нужен только для того, чтобы обеспечить наличие скроллбаров в клиентской области

Картинка такая на мой взгляд должна быть:
clmHeader1|clmHeader2|clmHeader3...
--------------------------------[^]
--------------------------------[|]
--------------------------------[|]
--------------------------------[|]
--------------------------------[v]
[<----------------------------->...

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

AK>и также генерирования сообщений скроллинга для окна.

Долго ли подписаться на события от VScrollBar? Там надо-то на ValueChanged подписаться да и всё. Ну и при отрисовке учитывать его размер.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[6]: VirtualGrid - ScrollableControl
От: Al-Ko  
Дата: 20.03.04 14:02
Оценка:
Здравствуйте, orangy, Вы писали:

O>Здравствуйте, Al-Ko, Вы писали:


AK>>ScrollableControl нужен только для того, чтобы обеспечить наличие скроллбаров в клиентской области

O>Картинка такая на мой взгляд должна быть:
clmHeader1|clmHeader2|clmHeader3...
--------------------------------[^]
--------------------------------[|]
--------------------------------[|]
--------------------------------[|]
--------------------------------[v]
[<----------------------------->...


да не совсем такая, а такая:

clmHeader1|clmHeader2|clmHeader3[^]
--------------------------------[|]
--------------------------------[|]
--------------------------------[|]
--------------------------------[|]
--------------------------------[v]
[<----------------------------->...




O>Т.е. хидеры не должны скроллиться,

безусловно
O>и скроллер не должен продолжаться на них.
должен — посмотри на любой грид, да хоть бы на тот, что в Хоуме
O>Второе еще можно игнорировать, но первое нельзя. А вот ScrollableControl — штука хитрая, он будет "оптимизировать" скроллинг, т.е. двигать битмапу, которую ты нарендерил на область контрола. И сначала скроллить её, а потом просить тебя нарисовать остаток. Не связывайтесь с ним, кривой он.
а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.

O>Долго ли подписаться на события от VScrollBar? Там надо-то на ValueChanged подписаться да и всё.

боюсь, что придется подписаться для каждого скроллбара на Scroll event и обрабатывать типы этого события SmallIncrement/Decrement, LargeIncrement/Decrement, ThumbTrack, а также еще события MouseWheel.
O>Ну и при отрисовке учитывать его размер.
Да, в этом случае нужно при ресайзинге контрола, а также при изменениях в строках/столбцах формировать "свой" client rectangle с учетом размеров скроллбаров, и все события мыши, скроллинга и отрисовку контролировать и осуществлять в нем.
Почему-то Влад выступает против этого способа. См.Re[12]: Completely managed TreeViewControl
Автор: Al-Ko
Дата: 30.01.04
(касательно скроллбаров) и ветки ниже.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[7]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 20.03.04 14:25
Оценка:
Здравствуйте, Al-Ko, Вы писали:

O>>Картинка такая на мой взгляд должна быть:

AK>
AK>clmHeader1|clmHeader2|clmHeader3...
AK>--------------------------------[^]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[v]
AK>[<----------------------------->...
AK>


AK>да не совсем такая, а такая:


AK>
AK>clmHeader1|clmHeader2|clmHeader3[^]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[v]
AK>[<----------------------------->...
AK>


Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма

O>>Второе еще можно игнорировать, но первое нельзя. А вот ScrollableControl — штука хитрая, он будет "оптимизировать" скроллинг, т.е. двигать битмапу, которую ты нарендерил на область контрола. И сначала скроллить её, а потом просить тебя нарисовать остаток. Не связывайтесь с ним, кривой он.

AK>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.
А смысл тогда им пользоватся?

O>>Долго ли подписаться на события от VScrollBar? Там надо-то на ValueChanged подписаться да и всё.

AK>боюсь, что придется подписаться для каждого скроллбара на Scroll event и обрабатывать типы этого события SmallIncrement/Decrement, LargeIncrement/Decrement, ThumbTrack, а также еще события MouseWheel.
Не придётся. По-крайней мере, мне не пришлось в моём виртуальном деревянном гриде

O>>Ну и при отрисовке учитывать его размер.

AK>Да, в этом случае нужно при ресайзинге контрола, а также при изменениях в строках/столбцах формировать "свой" client rectangle с учетом размеров скроллбаров, и все события мыши, скроллинга и отрисовку контролировать и осуществлять в нем.
Что-то вы, батенька, усложняете При нормально прописанной структуре контрола это элементарно всё...

AK>Почему-то Влад выступает против этого способа. См.Re[12]: Completely managed TreeViewControl
Автор: Al-Ko
Дата: 30.01.04
(касательно скроллбаров) и ветки ниже.

Почитаю.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[8]: VirtualGrid - ScrollableControl
От: Al-Ko  
Дата: 20.03.04 14:55
Оценка:
Здравствуйте, orangy, Вы писали:



O>Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма

ну мы же про грид говорим.

O>>>Второе еще можно игнорировать, но первое нельзя. А вот ScrollableControl — штука хитрая, он будет "оптимизировать" скроллинг, т.е. двигать битмапу, которую ты нарендерил на область контрола. И сначала скроллить её, а потом просить тебя нарисовать остаток. Не связывайтесь с ним, кривой он.

AK>>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.
O>А смысл тогда им пользоватся?
скроллбары не будут входить в ClientRectangle...
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[7]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 20.03.04 15:08
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Почему-то Влад выступает против этого способа. См.Re[12]: Completely managed TreeViewControl
Автор: Al-Ko
Дата: 30.01.04
(касательно скроллбаров) и ветки ниже.

Почитал ту ветку (честно скажу, по диагонали). Во многом не согласен с Владом, ну да это как обычно Например, я считаю абсолютно неверным рассчёт во время отрисовки. Мало того, что реакция контрола на требование перерисоваться замедляется, так еще и программно с ним работать сложнее становится. Прикинь на досуге реализацию функций:
int GetRowAt(int x, int y); // для хит-тестов разных, например для драг-дропа
int GetRowBottom(int index); // для выпадающего меню, чтобы строку не загораживало
void ScrollRowIntoView(int index); // для программного показа строки, например свежедобавленой

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

Что касается ScrollableControl и иже с ними... Попробуй с этим чудом поработать, сам поймёшь. Слишком много думать за программиста пытается. В этом вопросе с Владом я согласен, лучше делать свой скроллирующий контрол, но такой, какой надо. Насчёт же Авалона — я бы с этим пока не заморачивался, рано еще. Т.е. наследование может быть таким: Control -> ScrollableControlEx (это свой) -> VirtualGridBase -> ну и дальше клиенты.

Еще один момент. Не злоупотребляй интерфейсами. Они заставляют клиента (наследника VG) слишком много имплементировать. Например, если строки переменной высоты можно будет ресайзить, то должен быть предусмотрен какой-то механизм сообщения клиенту об этом для сохранения настроек. А если оно совсем не нужно клиенту? Не хотелось бы иметь VG, ради использования которого надо написать еще кучу кода, причём вида return false; или return null; Вообще не очень пониманию, зачем при общении базового класса с производным нужны какие бы то ни было интерфейсы, и так средств достаточно. Ну да вам виднее, вы уже много про это думали Удачи!
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[9]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 20.03.04 15:15
Оценка:
Здравствуйте, Al-Ko, Вы писали:

O>>Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма

AK>ну мы же про грид говорим.
И что? Я считаю, что пользователь должен визуально сразу понимать, что именно будет скроллиться.

AK>>>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.

O>>А смысл тогда им пользоватся?
AK>скроллбары не будут входить в ClientRectangle...
В большинстве случаев ты им пользоваться не будешь. При отрисовке тебя больше Clip интересует, при тыканьи мышкой — зоны хидеров и строчек отдельно. В моём гриде ClientRectangle встречается один раз — в защищенном свойстве ListRectangle, которое занимает 8 строчек кода. А такое свойство всё равно писать придётся. К примеру, при минимизации формы все размеры всех контролов на ней тоже становятся (0,0). Поэтому просто так вычесть высоту хидера нельзя — отрицательное число получится. А втыкать проверки в каждом месте не очень приятно.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[2]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Пожалуй пора продолжить .


Это... Ну, не сдесь же?! Эту ветку читают уже только самые самоотверженные. Я вот ее уже теряю.

Перемещайтесь в форум RSDN Research.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV> private bool _RowsHeightConst = true;


Вот это ненужно. Это не его ума дело. Будут егму отплевывать константу, будет высота строк одинаковой. Нет, и суда нет.

SAV> public bool RowsHeightConst

SAV> {
SAV> get { return _RowsHeightConst; }
SAV> set { _RowsHeightConst = value; }
SAV> }

Опять же, по тем же причинам.

SAV> private bool _ColumnsHeightConst = false;

SAV> public bool ColumnsHeightConst
SAV> {
SAV> get { return _ColumnsHeightConst; }
SAV> set { _ColumnsHeightConst = value; }
SAV> }

Это вообще ред какой-то.

SAV> private VGColumnCollection _Columns = new VGColumnCollection();

SAV> public VGColumnCollection Columns
SAV> {
SAV> get { return _Columns; }
SAV> set { _Columns = value; }
SAV> }

Все префиксы идут лесом. Только если они имена пересикаются с постоянно используемыми (из стандартных пространств имен).

SAV> private VGHorScroller _HorScroller;

SAV> public HorScroller HorScroller
SAV> {
SAV> get { return _HorScroller; }
SAV> set { _HorScroller = value; }
SAV> }

Здорово. Но почему не чистый интерфейс?

SAV>2. Интерфейс источника данных IVGDataSource — знает количество строк, предоставляет по запросу данные.


Вот это лишнее. Все должно быть универсально и без лишних приведений к object-ам. Интерфейс навигации должен заниматься исключительно навигацией. А данные должны отображаться пэинтерами строк. Которые и должны уже просить данные. ВГ в этом смысле только сборник алгоритомов. И алгоритмы отрисовки в его обязанности не входят.

SAV>
SAV>    public interface IVGDataSource
SAV>    {
SAV>        int RowsCount { get; }
SAV>        object GetData(int Row);
SAV>        event EventHandler DataChanged;
SAV>    }
SAV>


Во-во. И ты приплыл в да-баунд-модель.

SAV>4. Строка VGRow и коллекция строк VGRowCollection (на сколько я понимаю, наш грид полностью симметричен относительно колонок/строк)


И зачем вообще нужна коллекция строк? Он же виртуальный!

SAV>6. Некая абстракция для управления фокусом и выделением...


Во-во некая.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Если мы наследуемся от Control'а, то нам для обеспечения скроллинга нужно будет создавать свои контролы скроллбаров и лепить их к краям контрола.


Ну, почему? Можно и оконные скролеры поднять через виндузные средства. Главное, чтобы этим занимался отдельный класс.

AK>Преимущества такого подхода: не нужно лезть в WndProc и ловить WM_xSCROLL сообщения для окна, а обрабатывать только события Scroll этих скроллбаров. Недостатки: скроллбары будут находиться в клиентской области окна, поэтому придется каждый раз при вычислениях это учитывать;


Ну, это как раз фигня. Тут больше проблем с мерцанием будет. И с пересчетами при появлении/скрытии скроллеров.

AK> при одновременном появлении двух скроллбаров нужно лепить в правый нижний угол квадратик-панельку, для того, чтобы там не было дырки .


А это вообще никому не нужно. Ну, будет окно просчечивать и что?

AK>Если наследоваться от ScrollableControl или его наследников, то таких проблем не будет, но нужно будет работать с сообщениями окна.


Тоже не проблема. И вообще это задачи класса-скроллера.

AK>Короче, вроде как мы с Владом определились отталкиваться от второго варианта. Только надо вынести Scroller в отдельный класс, который потом можно будет заменить или изменить.


Вот именно. Причем последнее самое главное. Тогда по ходу можно будет махать все как хочешь.

AK>2. Интерфейс IVirtualGrid.


AK>Пока остановимся на этом:


AK>
AK>    interface IVirtualGrid
AK>    {
AK>        int RowsCount
AK>        int TopRow

ОК

AK>        bool CacheRowsHeight

А это что? Кэш же вроде ВГ делает. Или я уже все заблыл?

AK>        int GetBottomRow();

ОК.
AK>


Вот этот интерфейс больше похож на виртуальный.

AK>к этому интерфейсу будет обращаться грид-наследник.


Вопрос тольк с колонками. Если абстрагируем на уровне строки, то колонки ненужны. Если доходим до клонок, то их тоже нужно учесть.

AK>Дальше. Это частный случай, если строки и столбцы имеют неизменные размеры, это ОК:


SAV>> private bool _RowsHeightConst = true;

SAV>> private bool _ColumnsHeightConst = false;

Вот и пусть частный случай обрабатывается наследниками. Не нужно в абстракции честности загонять.

AK>это здесь не нужно:...


Вот именно.

AK>скроллеры пока убираем:

SAV>> private VGHorScroller _HorScroller;
SAV>> }

А вот это не ясно почему. Это как раз мне кажется нужно оставить. Только для интерфейса никаких классов не нужно. Только интерфейсы и ссылки на них.

AK>Это не нужно, с данными работает наследник VirtualGrid.


Именно! Чувствуешь как тяжело проникает в массы идея чистой абстракции?

AK>3. Теперь о столбцах и их коллекции.


AK>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого.

AK>После этого нужно двигаться дальше.

Однозначно компонентом. Но Михалик высказал одну мудрую, на мой взгляд, мысль. А именно он предложил абстрагироваться еще на уровне строки, а не колонки. Это кстати красиво вписывает текстовые редакторы в иерархию виртуальных контролов. Ведь редактор это грид без колонок (ну, или с одной скрытой колонкой).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, orangy, Вы писали:

O>Делать. Если у колонки появятся всякие события, например, HeaderRightClick, Sort или еще чего — тебе будет сложновато подписаться на эти события из дизайнера — придётся писать свой хитрый редактор коллекции с подпиской на сообщения, ну или делать это из кода. Кроме того, всё таки

O>
O>// удобнее писать 
O>clmName.ForeColor = Color.Red;
O>// чем 
O>grid.Columns["Name"].ForeColor = Color.Red;
O>

O>Только не забыть поставить [DesignTimeVisible(false)], чтобы в Component Tray они не болтались почём зря.

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

Мне больше нравится идея вообще не учитывать клонки в ВГ. Пусть этим занимется отдельный специализированный код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: VirtualGrid - фичи
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, orangy, Вы писали:

O>Так не получится. Как только у тебя появятся хидеры колонок, ты поимеешь кучу проблем с ScrollableControl, не говоря уж о тех проблемах, которые в нём есть от рождения — очень уж плохо управляется там скроллингом... Я пробовал и так и эдак, и через интероп — складывать скроллеры как внутренние контролы всяко удобнее.


Весь скролиг один фиг вручную переписывать. Так что это все фигня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>Здравствуйте, orangy, Вы писали:


O>>Здравствуйте, Al-Ko, Вы писали:


AK>>>ScrollableControl нужен только для того, чтобы обеспечить наличие скроллбаров в клиентской области

O>>Картинка такая на мой взгляд должна быть:
AK>
AK>clmHeader1|clmHeader2|clmHeader3...
AK>--------------------------------[^]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[v]
AK>[<----------------------------->...
AK>


AK>да не совсем такая, а такая:


AK>
AK>clmHeader1|clmHeader2|clmHeader3[^]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[|]
AK>--------------------------------[v]
AK>[<----------------------------->...
AK>


Скажу честно... я разницы не вижу.

O>>и скроллер не должен продолжаться на них.

AK>должен — посмотри на любой грид, да хоть бы на тот, что в Хоуме

Ну, он основан на ЛистВью — довольно примитивном и кривом контроле. Так что он не показателен.

AK>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.


Это как же? Не святым же духом он это делает.

AK>Почему-то Влад выступает против этого способа. См.Re[12]: Completely managed TreeViewControl
Автор: Al-Ko
Дата: 30.01.04
(касательно скроллбаров) и ветки ниже.


И еще раз напомню, что в основном из-за очень некрасвивого дерганья при перемещении скроллеров (кода они отдельные окна). Ну, и еще раз скажу, что обстрагируя скролинг в отдельном классе вообще снимается эта проблема. Если чтоо вегда можно переписать все как нужно. Главное, чтобы сам ВГ и его потомки не лезли рулить скролингом напрямую.

Мне, например, важно чтобы грид мог бы легко быть портирован на Авалон (где сролеры станут менеджед).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, orangy, Вы писали:

O>Почитал ту ветку (честно скажу, по диагонали). Во многом не согласен с Владом, ну да это как обычно Например, я считаю абсолютно неверным рассчёт во время отрисовки.


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

O> Мало того, что реакция контрола на требование перерисоваться замедляется, так еще и программно с ним работать сложнее становится.


Да по сравнению с отрисовкой замеделние просто незаметно будет. А вот по "программно с ним работать сложнее становится" ты в корен ошибаешся. Любое кэширование резко уложняет динамическое изменение контента.

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

O> Прикинь на досуге реализацию функций:

O>
O>int GetRowAt(int x, int y); // для хит-тестов разных, например для драг-дропа
O>int GetRowBottom(int index); // для выпадающего меню, чтобы строку не загораживало
O>void ScrollRowIntoView(int index); // для программного показа строки, например свежедобавленой
O>


И в чем пробелма? Последнее вообще какое-то кривое воплощение. Правильно было бы сделать метод:
bool EnsureVisible(int row, int col, bool isPartialOK);


Хотя дела это не меняет. Все эти методы реализуются в лучшем виде.

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

O>Конечно, это можно реализовать и так, и эдак, но всё-таки мне кажется, что лучше иметь готовый рассчитанный layout.


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

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


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

O>Что касается ScrollableControl и иже с ними... Попробуй с этим чудом поработать, сам поймёшь.


И что поймешь? Я как бы всю жизнь с ними работал и никаких проблем не испытывал.

O> Слишком много думать за программиста пытается. В этом вопросе с Владом я согласен, лучше делать свой скроллирующий контрол, но такой, какой надо.


Я не о контроле веду речь. Я о абстракции управляющей речь виду. Это разные вещи.

O> Насчёт же Авалона — я бы с этим пока не заморачивался, рано еще. Т.е. наследование может быть таким: Control -> ScrollableControlEx (это свой) -> VirtualGridBase -> ну и дальше клиенты.


Нет уж. Именно это и есть безграмотный подход. Короче, как делать скролеры уже вроде как давно решено. Что месить воду в ступе? Сроллер будет отдельным клкассом не унаследованным ни от кого. Просто классом. Получит в качестве инициализационных данных нужную информаци, ссылку на окно и т.п. и будет выплнять нужную работу. Захочет создаст скроблары отдельные, не захочет будет показывать скроллеры окна и общаться с ними по средствам месаг. Наследование тут (особненно в условиях отсуствия МН совсем ненужно).

O>Еще один момент. Не злоупотребляй интерфейсами. Они заставляют клиента (наследника VG) слишком много имплементировать.


Блин, где вы слова такие берете? Почему не реализовывать? Опять же все что нужно реализовывать пусть реализуют. В конце концов создать классы с референсными реализациями не сложно.

O> Например, если строки переменной высоты можно будет ресайзить, то должен быть предусмотрен какой-то механизм сообщения клиенту об этом для сохранения настроек.


Мля. Еще один. Прочти ту ветку что прочел вскльзь, но не вскльзь, а основательно. Тут ужу Михаликов м вредными советами хватает.

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

O> А если оно совсем не нужно клиенту?


Пусть не дергается.

O> Не хотелось бы иметь VG, ради использования которого надо написать еще кучу кода, причём вида return false; или return null; Вообще не очень пониманию, зачем при общении базового класса с производным нужны какие бы то ни было интерфейсы, и так средств достаточно. Ну да вам виднее, вы уже много про это думали Удачи!


Непонимаешь потому что плохо читал ту ветку. И потму что еще не натрахался в доволь с озданием монструозных всеумеек "помогающих" пользователю. Я этого счастья наелся достыта. Спасибо, больше не надо.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 21:32
Оценка:
Здравствуйте, orangy, Вы писали:

O>Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма


Ты когда в Ворде пишишь не сильно удевляешься, что скроллер заходит за линейки? А в Эксплорере что хидер захватывается? По мне так по фигу. Лиш бы работало.

O>А смысл тогда им пользоватся?


Скроллбарами? Ты сам то понял что спросил?

O>Не придётся. По-крайней мере, мне не пришлось в моём виртуальном деревянном гриде


Дык вопрос куда он при этом годится. Что же касается виртуального и деревянного — то это миф. Это невозможно в принципе. Как бы плавали...

O>Что-то вы, батенька, усложняете При нормально прописанной структуре контрола это элементарно всё...


В общем то сложного тут и правда не много. Но с оконными скроллерами и вообще ничего делать не нужно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.03.04 22:00
Оценка:
Итак, эта ветка себя изжила. Предлагаю переместится сюда Разработка интерфейсов Виртуального Грида
Автор: VladD2
Дата: 21.03.04
, и продолжить более конкретные обсуждения ужа там.

Я домыслил интерфейс ВГ. Просба критиковать, расширять и т.п. А так же попытаться продумать интерфейсы: IVirtualGridCallback и IScrollManager.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 21.03.04 19:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты когда в Ворде пишишь не сильно удевляешься, что скроллер заходит за линейки? А в Эксплорере что хидер захватывается? По мне так по фигу. Лиш бы работало.

Да фиг с ним, пусть будет хоть так, хоть эдак.

O>>А смысл тогда им пользоватся?

VD>Скроллбарами? Ты сам то понял что спросил?
Не понял ты меня, речь о конкретном ScrollableControl c конкретно выдернутыми ногами. Перечитай еще раз.

O>>Не придётся. По-крайней мере, мне не пришлось в моём виртуальном деревянном гриде

VD>Дык вопрос куда он при этом годится. Что же касается виртуального и деревянного — то это миф. Это невозможно в принципе. Как бы плавали...
Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[9]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 21.03.04 19:21
Оценка:
Здравствуйте, VladD2, Вы писали:

O>>Почитал ту ветку (честно скажу, по диагонали). Во многом не согласен с Владом, ну да это как обычно Например, я считаю абсолютно неверным рассчёт во время отрисовки.


VD>Что ж в свою очередь скажу, что так же не согласен с безапеляционностью высказываний одного товарища в одной статье по этому поводу. Но дела это не меняет.

Так что же статью не откомментировал соответственно? Я всё жду, жду, когда мне кто-нибудь по существу что-нибудь напишут...

O>> Мало того, что реакция контрола на требование перерисоваться замедляется, так еще и программно с ним работать сложнее становится.

VD>Да по сравнению с отрисовкой замеделние просто незаметно будет.
Но будет. А надо?

VD>А вот по "программно с ним работать сложнее становится" ты в корен ошибаешся. Любое кэширование резко уложняет динамическое изменение контента.

Причём здесь кэширование? Это просто расчёт контрола, где что находится, где какие размеры, куда что выводится и в каком состоянии находится.

VD>В общем, тут могу скзать только одно. Я выполнял подобную работу уже не один раз, и пришел именно к таким выводам. Интересно на чем основано твое мнение?

Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам

VD>Основной вопрос заключается в том, что при основные рассчеты или должны быть выполнимы во время отрисовки, или они будут дублироваться. Проверено на практике. В свое время именно отдельные рассчеты привели у нас к проблемам и плохой гибкости в их следсвии.

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

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

VD>Если ввести абстракцию строку и пэинтер строк, то делать можно будет как угодно. Но совмещать в одной реализации гордого оленя и тепетную лать точно ненадо.
Причём тут строка и painter? Размер резиновых колонок должен меняться при изменении размеров области данных грида, причём одна конкретная колонка или строка об этом и знать-то не должны. Это сущность выше строк и колонок. Можно конечно и потом прикрутить отдельный менеджер колонок или еще какую сущность, мне просто без этого никак, поэтому в моём гриде это есть. Вам может и не надо.

O>> Насчёт же Авалона — я бы с этим пока не заморачивался, рано еще. Т.е. наследование может быть таким: Control -> ScrollableControlEx (это свой) -> VirtualGridBase -> ну и дальше клиенты.

VD>Нет уж. Именно это и есть безграмотный подход. Короче, как делать скролеры уже вроде как давно решено.
Ну что же, ваше дело.

O>>Еще один момент. Не злоупотребляй интерфейсами. Они заставляют клиента (наследника VG) слишком много имплементировать.

VD>Блин, где вы слова такие берете? Почему не реализовывать?
Давай не будем о словах, ок? А то ты знаешь, что я могу на это сказать

VD>Непонимаешь потому что плохо читал ту ветку. И потму что еще не натрахался в доволь с озданием монструозных всеумеек "помогающих" пользователю.

Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно. Или я тебя не так понял?
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[10]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.04 18:45
Оценка:
Здравствуйте, orangy, Вы писали:

O>Так что же статью не откомментировал соответственно? Я всё жду, жду, когда мне кто-нибудь по существу что-нибудь напишут...


Я ее еще не дочитал. Всему свое время. Статья интересная... так что дочитаем и комментарии вставим.

Сейчас заняты разными клиент-серверами... так что не обессудь.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.04 23:27
Оценка:
Здравствуйте, orangy, Вы писали:

VD>>Да по сравнению с отрисовкой замеделние просто незаметно будет.

O>Но будет. А надо?

А есть проблемы? Оптимизировать нужно то что может дать выигрыш. Баросться за микросекунды когда основное время измеряется в десятых секунды просто глупо. К тому же от таких оптимизаций тормоза как раз и появляются.

O>Причём здесь кэширование?


А что такое по твоему предварительные рассчеты? Это и есть кэширование информации.

O> Это просто расчёт контрола, где что находится, где какие размеры, куда что выводится и в каком состоянии находится.


Во-во. И после него нужно после изменения содержимого менять еще и кэш. А так как реально рассчет проводимый в отрисовке аналогичен тому что до, то получаются лишние вычисления.

O>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам


Примеры можно поглядеть. Мой тут ascDB.

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


Зачем? Как раз при отрисовке все и рассчитывается. Потом можно уже пользоваться закэшированными данными. Хотя можно и посчитать. Клики мышами совершенно не требовательны к времени. Это тебе не отрисовка нескольких тысяч ячеек.

O>Причём тут строка и painter? Размер резиновых колонок должен меняться при изменении размеров области данных грида, причём одна конкретная колонка или строка об этом и знать-то не должны.


Ну, что могу понять. Хороший пример полного не понимания идеологии. Плохо ты читал ту ветку. Вот Al-Ko вроде бы меня понял. И как мне кажется оценил.

O> Это сущность выше строк и колонок.


Ложки нет (с)

O> Можно конечно и потом прикрутить отдельный менеджер колонок или еще какую сущность, мне просто без этого никак, поэтому в моём гриде это есть. Вам может и не надо.


Именно что можно. А раз можно, то нужно. Качественный грид — это очень сложная структура и чем больше будут абстрагированны отдельные конструкции, тем качественнее можно будет ее реализовать.

VD>>Блин, где вы слова такие берете? Почему не реализовывать?

O>Давай не будем о словах, ок? А то ты знаешь, что я могу на это сказать

Ладно, следующий раз будем лепить минусы.

O>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно.


Что-то это мнение расходится с мнением одного автора статей на нашем стайте.

O>Или я тебя не так понял?


То что ты назвал "чёткие небольшие контролы" на самом деле выраждается в слабые поделки. На горизонте нет ни одного приличного бесплатного грида или тривью, да и те что платные за частую не блещут. И виною тому как раз дизайн "все-в-одном"... который выливается в вечное создание убогого велосипеда.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.04 23:27
Оценка:
Здравствуйте, orangy, Вы писали:

O>Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?


Ага. Точноее в терминалогии. "Подкачивает" и "виртуальный" — это как бы две большие разница (с). Виртуальность подразумевает полное отсуствие хранения каких бы то нибыло ссылок на данные.

Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова. Мой грид конечно не виртуальный, да и не писался как супер-пупер, но вот с объемистыми данными я его таки научил работать. В общем, исходники моего грида доступны... выкладывай свои потестируем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 23.03.04 07:04
Оценка:
Здравствуйте, VladD2, Вы писали:

O>>Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?


VD>Ага. Точноее в терминалогии. "Подкачивает" и "виртуальный" — это как бы две большие разница (с). Виртуальность подразумевает полное отсуствие хранения каких бы то нибыло ссылок на данные.

Ну пусть будет так Хорошо, что пришли к пониманию

VD>Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова.

Это субъективное ощущение. Я писал как-то RSS-аггрегатор и в качестве теста залил в него свою янусовскую базу сообщений. Переключение между форумами происходило ощутимо быстрее, но не в разы, нет Тестить надо, не спорю, но см.ниже.

VD>В общем, исходники моего грида доступны... выкладывай свои потестируем.

Я рассматриваю вариант публикации своей библиотеки в open-source, даже с клиентом уже договорился, что на эту часть исходного кода он не претендует. Осталось найти время на документирование и приведение в порядок. Если всё пойдёт по плану, к лету будет доступно.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[11]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 23.03.04 07:04
Оценка:
Здравствуйте, VladD2, Вы писали:

O>>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам

VD>Примеры можно поглядеть. Мой тут ascDB.
Я посмотрю на досуге.

<..поскипано по причине несоответствия идеологии..>

O>>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно.

VD>Что-то это мнение расходится с мнением одного автора статей на нашем стайте.
Да ну?

O>>Или я тебя не так понял?

VD>То что ты назвал "чёткие небольшие контролы" на самом деле выраждается в слабые поделки.
Бывает и такое. Но если подходить к разработке контролов с умом, то получается хорошо.
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[12]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.03.04 12:24
Оценка:
Здравствуйте, orangy, Вы писали:

O>Здравствуйте, VladD2, Вы писали:


O>>>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам

VD>>Примеры можно поглядеть. Мой тут ascDB.
O>Я посмотрю на досуге.

O><..поскипано по причине несоответствия идеологии..>


O>>>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно.

VD>>Что-то это мнение расходится с мнением одного автора статей на нашем стайте.
O>Да ну?

Ага. Он как-то пел песню о том, что один универсальный контрол поддерживать проще чем... И чего это он?

O>Бывает и такое. Но если подходить к разработке контролов с умом, то получается хорошо.


И где их результаты? Кинь плиз ссылку.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.03.04 12:24
Оценка:
Здравствуйте, orangy, Вы писали:

VD>>Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова.

O>Это субъективное ощущение. Я писал как-то RSS-аггрегатор и в качестве теста залил в него свою янусовскую базу сообщений. Переключение между форумами происходило ощутимо быстрее, но не в разы, нет Тестить надо, не спорю, но см.ниже.

Ну, то что ты там заливал я не видел. И вообще проблемы производительности джета к гридам как бы отношение имеют опостедованное. Ты создай чистый тест, без БД и с одинаковыми характиристиками. Я на подобных добавлял миллион объектов, например. Попрбуй сделать это на своей реализации...

VD>>В общем, исходники моего грида доступны... выкладывай свои потестируем.

O>Я рассматриваю вариант публикации своей библиотеки в open-source, даже с клиентом уже договорился, что на эту часть исходного кода он не претендует. Осталось найти время на документирование и приведение в порядок. Если всё пойдёт по плану, к лету будет доступно.

Ну, что же. Вот тогда и померяем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 23.03.04 12:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты создай чистый тест, без БД и с одинаковыми характиристиками. Я на подобных добавлял миллион объектов, например. Попрбуй сделать это на своей реализации...

Что значит миллион объектов? Миллион узлов? Сколько на верхнем уровне, сколько вложенных? Вложенные сразу добавлялись или по мере раскрытия веток? Подгрузка данных по мере показа узлов была или сразу всё заполнялось?

VD>Ну, что же. Вот тогда и померяем.

Всё бы тебе меряться
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[13]: VirtualGrid - ScrollableControl
От: orangy Россия
Дата: 23.03.04 12:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Он как-то пел песню о том, что один универсальный контрол поддерживать проще чем... И чего это он?

Слушай, Влад, давай ты еще раз прочитаешь этот абзац и прочитаешь внимательно, пытаясь понять, что же хотел сказать этот автор, а не то, что ты хотел увидеть?! Между прочим, слова "универсальный" там нет и в помине. И буквально следующее предложение уточняет специально для тех, кто понимает по-своему...

>:-E
... << RSDN@Home 1.1.3 beta 2 >>
"Develop with pleasure!"
Re[14]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.03.04 12:02
Оценка:
Здравствуйте, orangy, Вы писали:

O>Слушай, Влад, давай ты еще раз прочитаешь этот абзац и прочитаешь внимательно, пытаясь понять, что же хотел сказать этот автор, а не то, что ты хотел увидеть?! Между прочим, слова "универсальный" там нет и в помине. И буквально следующее предложение уточняет специально для тех, кто понимает по-своему...


Чего и вам желаю (с).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.03.04 12:02
Оценка:
Здравствуйте, orangy, Вы писали:

O>Что значит миллион объектов? Миллион узлов?


Да.

O>Сколько на верхнем уровне, сколько вложенных?


Для моей реализации по фигу.

O>Вложенные сразу добавлялись или по мере раскрытия веток? Подгрузка данных по мере показа узлов была или сразу всё заполнялось?


Сразу. По мере открытия это ты устанешь открывать.

VD>>Ну, что же. Вот тогда и померяем.

O>Всё бы тебе меряться

А чё очень приличное хобби.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: VirtualGrid - ScrollableControl
От: KGP http://kornilow.newmail.ru
Дата: 11.05.04 10:56
Оценка:
Здравствуйте, orangy, Вы писали:

O>Здравствуйте, Al-Ko, Вы писали:


AK>>
AK>>clmHeader1|clmHeader2|clmHeader3[^]
AK>>--------------------------------[|]
AK>>--------------------------------[|]
AK>>--------------------------------[|]
AK>>--------------------------------[|]
AK>>--------------------------------[v]
AK>>[<----------------------------->...
AK>>

Ну да ... и все колонки должны будут вмещаться в текущую ширину ... ? clmHeader4 тогда ни как (управление динамическое) а что делать будете, когда пользователь сожмёт область видимую по ширине ?
... << RSDN@Home 1.1.2 stable >>
Re[9]: VirtualGrid - ScrollableControl
От: Al-Ko  
Дата: 11.05.04 12:58
Оценка:
Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, orangy, Вы писали:


O>>Здравствуйте, Al-Ko, Вы писали:


AK>>>
AK>>>clmHeader1|clmHeader2|clmHeader3[^]
AK>>>--------------------------------[|]
AK>>>--------------------------------[|]
AK>>>--------------------------------[|]
AK>>>--------------------------------[|]
AK>>>--------------------------------[v]
AK>>>[<----------------------------->...
AK>>>

KGP>Ну да ... и все колонки должны будут вмещаться в текущую ширину ... ? clmHeader4 тогда ни как (управление динамическое)
а зачем скроллбар горизонтальный? На этой схеме он представлен стрелочками внизу.
KGP>а что делать будете, когда пользователь сожмёт область видимую по ширине ?
отобразим изменения на скроллбаре. Что тебя смущает в этом вопросе? Возьми TreeGrid в Хоуме и посмотри на его поведение.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[10]: VirtualGrid - ScrollableControl
От: KGP http://kornilow.newmail.ru
Дата: 11.05.04 13:24
Оценка:
Здравствуйте, Al-Ko, Вы писали:
Возможно я контекст не понял :
O>Т.е. хидеры не должны скроллиться,
безусловно


И вертикальная и горизонтальная проктурки будут работать по-пиксельно или по-записи(колонке) ?
... << RSDN@Home 1.1.2 stable >>
Re[11]: VirtualGrid - ScrollableControl
От: Al-Ko  
Дата: 11.05.04 13:38
Оценка:
Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, Al-Ko, Вы писали:

KGP>Возможно я контекст не понял :
O>>Т.е. хидеры не должны скроллиться,
KGP>безусловно
я имел ввиду не должны скроллиться вертикально. А горизонтально должны.

KGP>И вертикальная и горизонтальная проктурки будут работать по-пиксельно или по-записи(колонке) ?

оба способа имеют право на жизнь Надо делать и тот и другой.
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re[12]: VirtualGrid - ScrollableControl
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.05.04 21:03
Оценка:
Здравствуйте, Al-Ko, Вы писали:

AK>оба способа имеют право на жизнь Надо делать и тот и другой.


Именно. Но не по одному пикселю а хотя бы по 5-10. А то это выглядит как издевательство.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Простой, быстрый, бесплатный грид
От: Vladimir_Vovk  
Дата: 21.05.04 02:29
Оценка: 27 (1)
Здравствуйте, SiAVoL, Вы писали:

SAV>Вот ищу сабж. Основные требования:

SAV> SAV>В общем требований немного Редактирования, группирования данных и прочих изысков не надо. Желательно что бы грид был с исходниками.
SAV>Покопал на www.codeproject.com, ничего хорошего не нашел. Сейчас смотрю на TreeGrid из януса. Вроде бы пока вполне устраивает (на сколько я знаю его использование не запрещено ), но это все-таки Tree грид и возиться с ITreeNode особой необходимости нет.
SAV>В общем может ли мне кто-нибудь порекомендовать хороший грид?

Попробуйте зайти на сайт www.codeguru.ru, я встречал там подобные вещи (может и вам что-то подойдет )
Re[2]: Простой, быстрый, бесплатный грид
От: Al-Ko  
Дата: 21.05.04 13:59
Оценка:
Здравствуйте, Vladimir_Vovk, Вы писали:

V_V>Попробуйте зайти на сайт www.codeguru.ru, я встречал там подобные вещи (может и вам что-то подойдет )


ссылка битая
... << RSDN@Home 1.1.3 stable >>
Старый глюк лучше новых двух!
Re: Простой, быстрый, бесплатный грид
От: Vladimir_Vovk  
Дата: 09.06.04 10:27
Оценка:
Здравствуйте, SiAVoL, Вы писали:

SAV>Вот ищу сабж. Основные требования:

SAV> SAV>В общем требований немного Редактирования, группирования данных и прочих изысков не надо. Желательно что бы грид был с исходниками.
SAV>Покопал на www.codeproject.com, ничего хорошего не нашел. Сейчас смотрю на TreeGrid из януса. Вроде бы пока вполне устраивает (на сколько я знаю его использование не запрещено ), но это все-таки Tree грид и возиться с ITreeNode особой необходимости нет.
SAV>В общем может ли мне кто-нибудь порекомендовать хороший грид?

Попробуйте посмотреть на www.codeguru.com
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.