Здравствуйте, fddima, Вы писали:
F>Лично меня в нем не устраивает, что в Read Only режиме, все клеточки все одно выделяются, Single Row (и соотв.) выделение нормально сделать не выходит. Текст если не влазит в строку форматируется только если стать на ячейку (если высота строки позволяет отобразить)... короче дофига всего не так
Ну это все можно и в стандартном гриде сделать через своих наследников System.Windows.Forms.DataGridColumnStyle
Но мы все-равно сделаем лучше
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
AK>>TypeConverter AK>>TypeEditor AK>>TypePainter
VD>Зачем Type? Одни и те же типы данных можно отобразать по разному.
вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.
AK>да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей
Я имею в виду не сам процесс выделения, а хранение списка выделенных ячеек.
Или ты хочешь хранить список выделенных прямоугольников, а не ячеек? Это что-то остроумное, но подозрительное. Пользователю будет непривычно, наверное. Внутри одна ячейка удалилась, и выделенные прямоугольники остались на месте?
M>>P.S. Лично меня в этом проекте больше всего интересует первая вступительная часть, а именно толковый ScrollableControl. То есть, как вы будете делать полосы прокрутки, вот что было бы полезно посмотреть.
AK>можно не только посмотреть, но и попринимать участие. Так что вэлкам!
Будем посмотреть. Пока вот разве что мысли подкинуть могу, времени маловато
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. И, кажется, виртуальность тоже появилась.
Скоро бета, а там и релиз. Обстановка для гридописательства накаляется.
Здравствуйте, mihailik, Вы писали:
AK>>да как раз мультивыделение несложно. Выделение — это всего лишь добавление прямоугольных областей
M>Я имею в виду не сам процесс выделения, а хранение списка выделенных ячеек.
я тоже. Храни их в виде списков прямоугольников областей выделения, например:
рассортируй эти ректанглы как тебе удобно, и проверяй, входит ли твоя ячейка в область выделения
M>Или ты хочешь хранить список выделенных прямоугольников, а не ячеек? Это что-то остроумное, но подозрительное. Пользователю будет непривычно, наверное.
а что пользователю? Он будет иметь два метода: IsCellHighlighted и HighlightCells(те же четыре координаты)
M>Внутри одна ячейка удалилась, и выделенные прямоугольники остались на месте?
во-первых, объясни, как это: одна ячейка удалилась? Удалиться может только строка или столбец. В этом случае можно скорректировать коллекцию ректанглов. А во-вторых, в большинстве случаев удаления подсветка либо убирается вообще (в гриде) или остается на том же месте (в спредшите).
M>Будем посмотреть. Пока вот разве что мысли подкинуть могу, времени маловато
мысли — это самое ценное и есть
Здравствуйте, mihailik, Вы писали:
M>>>Именованы? Ну, Text или там Caption понятно. Но Name вроде ни к чему AK>>а чтобы обращаться к столбцам myGrid.Columns["MyName"]
M>А какая в этом бывает необходимость?
ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ...
и все дела. Удобно?
M>>Внутри одна ячейка удалилась, и выделенные прямоугольники остались на месте? AK>во-первых, объясни, как это: одна ячейка удалилась? Удалиться может только строка или столбец.
Да, строка. Типа, обновили Refresh, и там больше этой позиции нету.
AK> В этом случае можно скорректировать коллекцию ректанглов. А во-вторых, в большинстве случаев удаления подсветка либо убирается вообще (в гриде) или остается на том же месте (в спредшите).
Да, похоже, что ты прав. Надо подумать, всё-таки этот подход мне внутри коробит.
AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ... AK>и все дела. Удобно?
Не очень. Мало ли, ошибёшься вместо "Totals" напишешь "Total". Удобно так: totalsColumnHeader.BackColor=...
То есть наследовать ColumnHeader от Component и пусть он будет полноправным компонентом с полем в DesignTime.
Здравствуйте, mihailik, Вы писали:
AK>>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ... AK>>и все дела. Удобно?
M>Не очень. Мало ли, ошибёшься вместо "Totals" напишешь "Total". Удобно так: totalsColumnHeader.BackColor=... M>То есть наследовать ColumnHeader от Component и пусть он будет полноправным компонентом с полем в DesignTime.
можно и так. А может быть, и нужно. Будем обсуждать. В конце концов, стили столбцов в датагриде устроены именно так.
Здравствуйте, Al-Ko, Вы писали:
AK>вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.
Под "дизайнером" ты имешь в виду проперти-грид?
Ну, тут скажем так не все грамотно. Многое сложно (та же кастом-отрисовка сделана очень сложно и криво). Хотя идея с UIEditor-ом в принципе правильная. Только опять таки неполноценная.
В общем, я бы взял лучшее, но ориентировался бы на собственную реализацию. Как вариант универсальный эдитор позволяющий использовать дотнетные средства.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ... AK>и все дела. Удобно?
Фигово. Прикинь что будет если понадобится локализация.
"AndrewVK" <5161@news.rsdn.ru> wrote in message news:557631@news.rsdn.ru... > Здравствуйте, Al-Ko, Вы писали: > > AK>ну захочу я окрасить столбец "Итоги" красным цветом. Я не знаю его номер (он может и меняться). Но я пишу myGrid.Columns["Totals"].BackColor = ... > AK>и все дела. Удобно? > > Фигово. Прикинь что будет если понадобится локализация.
AK>Строки
AK> высота
AK> изменяема в run-time
AK> оптимально рассчитывается для содержимого ячеек
AK> одинаковая для всех строк
AK> может быть разной
Что то я не совсем понял такое разбиение... Мне думается есть всего два варианта:
[list]
[*] Изменяемая высота
[*] Постоянная высота
[/list]
В случае изменяемой может быть два варианта:
- наследник передает ВГ (виртуальный грид) высоты строк и ВГ на эти высоты никак повлиять не может.
- ВГ опять же получает высоты от наследника, но пользователь может изменять высоту строки через ВГ (мышкой), в этом случае ВГ уведомляет наследника об этих изменениях
AK>Сетка
Выделение этого пункта мне кажется лишним. Сетка - это проблемы наследника, имхо.
AK>Выделение (Highlighting)
Это тоже сложный вопрос. Предлагаю сначала разобраться с тем, кто за что отвечает (где обязанности ВГ, а где наследника)
Я так понимаю, что строка вполне может принять такой вид
[code]
*********************************
* * 2 * 3 *
* 1 *****************************
* * 4 * 5 *
*********************************
Причем сам ВГ об этих сцеплениях (а не исключены и большие извращения ) представления не имеет. Таким образом возникает вопрос: как ВГ будет рисовать сетки и выделять ячейки? Если же ВГ будет знать обо всем этом, то мы потеряем в гибкости и заложим ВГ лишний функционал, который должен быть вынесен отдельно.
Вот что я думаю о ВГ:
он знает общее количество строк и столбцов
он знает какие из них в данный момент отображаются на экране
он делегирует их отрисовку в специальные подключенные к нему абстракции.
он сообщает наследнику событиях мыши и клавиатуры
знает текущую строку и столбец
взаимодействует с абстракцией навигации и изменяет текущую строку и столбец. соответствующим образом изменяет список отображаемых строк и столбцов
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Al-Ko, Вы писали:
AK>>вот и делай им разные эдиторы и пэйнтеры. Я считаю, что система должна быть такая же, как в дизайнере.
VD>Под "дизайнером" ты имешь в виду проперти-грид?
ну да
VD>В общем, я бы взял лучшее, но ориентировался бы на собственную реализацию. Как вариант универсальный эдитор позволяющий использовать дотнетные средства.
согласен
Здравствуйте, SiAVoL, Вы писали:
SAV>Ну это все можно и в стандартном гриде сделать через своих наследников System.Windows.Forms.DataGridColumnStyle SAV>Но мы все-равно сделаем лучше
Та я в принципе в курсе, просто не успел еще Функциональность важнее отображения типа... В общем болею всем телом за ваше "лучше"! Спасибо
Здравствуйте, AndrewVK, Вы писали:
AK>>Но я пишу myGrid.Columns["Totals"].BackColor = ...
AVK>Фигово. Прикинь что будет если понадобится локализация.
а при чем здесь локализация? Это всего лишь внутренний индекс для обращения к конкретному столбцу. Не целочисленный, а строковый.
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Al-Ko, Вы писали:
AK>>
AK>>Строки
AK>> высота
AK>> изменяема в run-time
AK>> оптимально рассчитывается для содержимого ячеек
AK>> одинаковая для всех строк
AK>> может быть разной
AK>>
SAV>Что то я не совсем понял такое разбиение... Мне думается есть всего два варианта: SAV>
SAV> Изменяемая высота SAV> Постоянная высота SAV>SAV>В случае изменяемой может быть два варианта: SAV> — наследник передает ВГ (виртуальный грид) высоты строк и ВГ на эти высоты никак повлиять не может. SAV> — ВГ опять же получает высоты от наследника, но пользователь может изменять высоту строки через ВГ (мышкой), в этом случае ВГ уведомляет наследника об этих изменениях
я здесь хотел акцентировать внимание, что высота, независимо от того изменяема ли она, или постоянна, может быть одинаковой для всех строк, а может быть разной. В том случае, если она одинакова для всех строк, нам не нужно включать многие механизмы виртуал грида. Т.е. просто описан частный (и довольно частый) случай, который можно задавать в настройках (IMHO, конечно). AK>>Сетка SAV>Выделение этого пункта мне кажется лишним. Сетка — это проблемы наследника, имхо.
я думал, что проблема наследника — это нарисовать сетку. Проблема ВГ состоит в том, чтобы дать наследнику команду на ее рисование. Чтобы дать команду, нужно знать настройки для сетки. Наличие или отсутсвие сетки — это как бы общая часть всех гридов. Отрисовка сетки — это вопрос наследника.
AK>>Выделение (Highlighting) SAV>Это тоже сложный вопрос. Предлагаю сначала разобраться с тем, кто за что отвечает (где обязанности ВГ, а где наследника) SAV>Я так понимаю, что строка вполне может принять такой вид SAV>
SAV>Причем сам ВГ об этих сцеплениях (а не исключены и большие извращения ) представления не имеет. Таким образом возникает вопрос: как ВГ будет рисовать сетки и выделять ячейки? Если же ВГ будет знать обо всем этом, то мы потеряем в гибкости и заложим ВГ лишний функционал, который должен быть вынесен отдельно.
в этом случае сетка рисуется после отрисовки очередной ячейки. ВГ после обработки отрисовки ячейки смотрит, есть ли у него вертикальная сетка. Если есть, он говорит наследнику — рисуй ее. После того, как все ячейки в строке отрисованы, он проделывает тоже самое с горизонтальной сеткой. Что касается выделения, то попробуй смоделировать нарисованную тобой ситуацию в Excel и посмотри, как там просто все решается.
SAV>Вот что я думаю о ВГ: SAV>
SAV> он знает общее количество строк и столбцов SAV> он знает какие из них в данный момент отображаются на экране SAV> он делегирует их отрисовку в специальные подключенные к нему абстракции. SAV> он сообщает наследнику событиях мыши и клавиатуры SAV> знает текущую строку и столбец SAV> взаимодействует с абстракцией навигации и изменяет текущую строку и столбец. соответствующим образом изменяет список отображаемых строк и столбцов SAV> абсолютно согласен.
SAV>В общем надо думать...
абсолютно согласен.