Petro123Кроме того, есть базовый функционал грида, который всё увеличивается в современном мире.
Как правило большинство функций в гриде в каком-нибудь конкретном проекте не нужны, а некоторые навороты могут вообще никогда не понадобятся. Сваливать все функции в один грид - это не айс, а точнее перегруз. В принципе один из минусов в компонентной разработке - перегрузка классов компонентов функциями и свойствами в угоду компонентному методу в разработке приложений. Под перегрузкой я понимаю слишком большое количество функций, методов и свойств в одном классе. Если с проектной точки зрения смотреть - то это перегрузка обязанностей, т.е. когда одному классу дают слишком много обязанностей, и то не своих, которые по логике нужно поручать другим классам. А лишние классы делать - лишние компоненты...
Petro123
Базовый класс - "просто сетка" может кому и нужен, но только для эстетов.
Ну вообще два подхода я вижу:
1) Есть готовое и это готовое нужно подделать/подкоректировать под свою задачу.
2) Есть основа, конструктор - мы сразу собираем, что нам нужно.
Тут весь вопрос, сколько в конкретной задаче время может занять тот или иной подход.
Иногда на корректировку готового напильником уходит больше времени, чем сборка из конструктора. Но это не значит, что нужно всегда все собирать из конструкторов, тем более если готовое быстро адаптируется под данную задачу.

AlexJm,

>Отлично. То есть правильным решением будет свалить в проект 25 типов сеток от мала до >велика и развлекаться всю оставшуюся жизнь?

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