Здравствуйте, Al-Ko, Вы писали:
AK>я отправил на vc(at)rsdn.ru текст статьи для согласования. Нужно добавить технические подробности (см.последний пункт статьи)
У нас тут перезд на новый сервер. Почта неработает.
Публику пока что здесь.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Разрабатывая пользовательский интерфейс приложений, программисты нередко сталкиваются с необходимостью отображать данные в табличной форме. Наиболее подходящим элементом управления для этого является грид. В рамках данного проекта, средствами .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 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>VirtualGrid — абстрактный базовый класс, предназначенный для реализации общих для всех многострочных контролов механизмов: AK>" управление фокусом ввода и подсветкой (Highlighting) AK>" управление коллекцией столбцов
По поводу этих двух пунктов. Мне кажется стоит оставить возможность наследнику изменить эти механизмы. Т.е. их надо выделить в отдельные абстракции и поставлять с виртуальным гридом стандартную реализацию (по умолчанию). А при желании их можно заменить на что-то свое.
AK>Управление коллекцией столбцов AK>В отличие от строк, виртуальный грид должен хранить самую полную информацию о данных своих столбцов, поддерживая их полноценную коллекцию, сериализуемую в код. Помимо своего целочисленного индекса, столбцы должны быть именованы, грид должен знать их ширину, располагать информацией о хидерах и футерах. Также необходимо учитывать, что заголовки столбцов могут быть составными и "склееными" между соседними колонками.
Опять же здесь у меня есть сомнения. Мы не сможем в виртуальном гиде предусмотреть все возможные извращения с колонками. Мне кажется от этого надо абстрагироваться
Здравствуйте, SiAVoL, Вы писали:
SAV>По поводу этих двух пунктов. Мне кажется стоит оставить возможность наследнику изменить эти механизмы. Т.е. их надо выделить в отдельные абстракции и поставлять с виртуальным гридом стандартную реализацию (по умолчанию). А при желании их можно заменить на что-то свое.
так и будет
SAV>Опять же здесь у меня есть сомнения. Мы не сможем в виртуальном гиде предусмотреть все возможные извращения с колонками. Мне кажется от этого надо абстрагироваться
все правильно. Пока точно не знаю как, но предусматривается вынести механизм склеивания в отдельный класс, скажем, Merger. Наследники будут реализовывать (или дополнять) его в соответствии со своими нуждами.
Здравствуйте, SiAVoL, Вы писали:
SAV>Думается надо по-маленьку сочинять список основных абстракций с обязанностями и кратким интерфейсом.
да, сейчас составлю список фич, потом можно и это
SAV>Кстати как у нас с CVS?
пока тихо
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 должен в базовой реализации возвращать константу. Расчитывать от размера текста дорого.
Здравствуйте, Al-Ko, Вы писали:
AK>все правильно. Пока точно не знаю как, но предусматривается вынести механизм склеивания в отдельный класс, скажем, Merger. Наследники будут реализовывать (или дополнять) его в соответствии со своими нуждами.
Надо бы предусмотреть и то, что бывают и отличные от склеивания механизмы работы с ячейками. Так бывают рзные области. То есть одна область содержит две колонки, другая три. Они перемежаются... Еще бывает когда дрвесные структуры имют разный набор колонок в разных уровнях.
В общем, тут нужно ооочнь серьезно подумать.
Отдельной пробемой является задание всей этой фигни. Задавть это программно дико неудобно. Нужно делать нечто вроде того что сделано в таблицах HTML-я или еще что.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Любое видение полезно. Даже совсем противопложенное.
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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
M>Это всё фигня по сравнению с мультивыделением. Если мы поддерживаем мультивыделение, нам приходится хранить список выделеных ячеек.
M>Или номеров ячеек? Ага, вот в том и дело, что не всё так просто. Если наш грид отображает некоторую коллекцию, то на что будем равняться: на номер или на объект-элемент?
да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей, независимо от того, одну ячейку ты выделяешь, или группу. То есть фактически мы имеем здесь определенным образом устроенную коллекцию из Rectangle. Поскольку ты выделяешь в интерактивном режиме, ничто не мешает упорядочить эту коллекцию так, чтобы поиск того, входит ли очередная отрисовываемая ячейка в область выделения, не занимал много времени.
M>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.
можно не только посмотреть, но и попринимать участие. Так что вэлкам!
Здравствуйте, mihailik, Вы писали:
AK>> Помимо своего целочисленного индекса, столбцы должны быть именованы
M>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему
а чтобы обращаться к столбцам myGrid.Columns["MyName"]
VD>Нужно выделить список фич и описать каждую в отдельности. Например:
Перед проектированием остановимся на основных возможностях VirtualGrid и его элементов: строки
столбцы
полосы прокрутки
сетка
выделение (Highlighting)
фокус и Selection
Строки
высота
изменяема в run-time
оптимально рассчитывается для содержимого ячеек
одинаковая для всех строк
может быть разной
статус в гриде
пользовательские (обычные, могут вертикально прокручиваться в области изображения)
фиксированные (не прокручиваются при вертикальном скроллинге, всегда видны в области изображения)
строки хидеров
строки футеров
"замороженные пользователем"
поведение
могут добавляться/удаляться
могут перемещаться
Столбцы
ширина
изменяема в run-time
оптимально рассчитывается для содержимого ячеек
одинаковая для всех столбцов
может быть разной
статус в гриде
пользовательские (обычные, могут горизонтально прокручиваться в области изображения)
фиксированные (не прокручиваются при горизонтальном скроллинге, всегда видны в области изображения)
левые фиксированные
правые фиксированные
"замороженные пользователем"
поведение
могут добавляться/удаляться
могут перемещаться
Скроллинг
полосы прокрутки
не отображаются
отображаются всегда
отображаются автоматически
направление
только вертикальный
только горизонтальный
и вертикальный и горизонтальный
поведение
плавная прокрутка
дискретная прокрутка (по ширине столбца и по высоте строки)
только по столбцам (по строкам плавная)
только по строкам (по столбцам плавная)
и по столбцам и по строкам
Сетка
видимость
не видна
только горизонтальная
только вертикальная
и горизонтальная и вертикальная
Выделение (Highlighting)
вид
только строки целиком
только столбцы целиком
произвольное выделение ячеек
только смежных областей
мультивыделение любых ячеек
способ
используя заголовки строк или столбцов
не используя заголовки
Фокус и Selection
вид
только одной ячейки
строки целиком
столбца целиком
и строки и столбца целиком
Просьба добавить/пометить_на_удаление нужное/ненужное. Я потом оформлю все это в виде таблицы
VD>Далее нужно выделить этапы. Ну, там проектирование интерфейсов. Проктирование, фич. Реализация фич: х, у... Причем все это нужно подгадать так, чтобы максимально быстро можно было бы получить рабочий прототип.
после того как утвердим список фич
VD>Так же нужно более четко описать набор контролов-наследников. Возможно даже с указанием тех приемуществ которые они получаят от грида. Это позволит более четко сформулировать необходимые требования.
Я точно вижу здесь:
1) TreeGrid
2) RectangularGrid c возможностью полноценного редактирования ячеек разного типа
3) Spreadsheet c возможностью полноценного редактирования ячеек разного типа, склеивания ячеек — короче а-ля Excel
Здравствуйте, Al-Ko, Вы писали:
AK>можно не только посмотреть, но и попринимать участие. Так что вэлкам!
Самого очень интересует грид... скоро нужен будет, а стандартный как всегда в отстойнике
Лично меня в нем не устраивает, что в Read Only режиме, все клеточки все одно выделяются, Single Row (и соотв.) выделение нормально сделать не выходит. Текст если не влазит в строку форматируется только если стать на ячейку (если высота строки позволяет отобразить)... короче дофига всего не так Так что начинание хорошее А вот собственно сам не думаю что буду полезен...
Здравствуйте, Al-Ko, Вы писали:
AK>Я точно вижу здесь:
AK>2) RectangularGrid c возможностью полноценного редактирования ячеек разного типа
Я правильно понимаю, что это подразумевает собой подстраивание под тип как при отображении, так и при редактировании? Типа bool -> checkbox, enum -> combobox, etc.?
Здравствуйте, agra, Вы писали:
A>Я правильно понимаю, что это подразумевает собой подстраивание под тип как при отображении, так и при редактировании? Типа bool -> checkbox, enum -> combobox, etc.?
тут не то чтобы подстраивание. Для работы с любым типом данных в гриде нам нужно иметь:
TypeConverter
TypeEditor
TypePainter
Для стандартных типов они будут стандартными, а для пользовательских — нужно будет наследоваться. Нужно сделать так, чтобы в дизайне можно было перетянуть в столбец грида любой контрол из меню Toolbox'а, и грид мог с ним работать в рантайме либо без дополнительных телодвижений, либо с помощью наследников этих классов.
.
