Так получилось, что рассказывать о переводе приложения с GridEh на DevExpress‘овские гриды бессмысленно, если читатель не имеет представления о cxGrid. Отсюда и затянувшаяся серия “заметок на полях“. К слову, на мой взгляд по соотношению цена/функционал GridEh - все таки оптимальное решение. Тем не менее, как я писал в предыдущем посте серии, была необходимость использовать cxGrid.
Скажу честно, процесс перевода не прост. Хотя во многом его трудоемкость зависит от организации исходного варианта. В моем случае события исходных гридов обрабатывались очень плотно. Перед моим предшественником ставилась задача получить определенную эргономику грида. Переход по ячейкам с помощью Enter, новая запись по достижению последней ячейки последней записи и т.д. Кроме этого, при добавлении записей в грид производились некоторые операции по подстановке исходных значений (почему в грид, а не в датасет, я так и не понял), изменению отображения данных и прочее… Все это и привело к весьма громоздкому и “гридзависимому” коду.
После удаления старого грида и водружения на его места нового, компилятор выдавал по нескольку сотен ошибок. К счастью большинство из них были однотипными. Хотя конструкции вида
DataSet := GridEh1.DataSource.DataSet;
с последующими
DataSet.FieldByName(gstrFIELD_TIME_FROM).AsDateTime := <...какой-то там код...>;
приводили в трепет. Все это выливалось в
DataSet :=(cxDBGrid.Views[0] as TcxGridDbTableView) .DataController.DataSource.DataSet;
Зачем все это изначально делалось- ясно. Что бы можно было к гриду “прицепить” другой датасет без потери его (грида) функциональности. Однако, на практике, в коде датасет не менялся. Поэтому, частенько в окончательном коде у меня стали появляться такие строки:
DataSet := qryTiming; //(cxDBGrid.Views[0] as TcxGridDbTableView).DataController.DataSource.DataSet;
А потом и вовсе:
qryTimingTimeFrom.AsDateTime := <...какой-то там код...>;
Заметьте, если бы изначально в код не закладывалась потенциальная и не востребованная универсальность, все было бы много проще. Хотя с другой стороны, ни одна строка кода в обработчиках событий не осталась незамеченной.
Надо обратить внимание, что увязать события грида тоже было довольно сложно. Порой приходилось очень долго искать соответствия между GridEh и TcxGridDbTableView. И много событий просто выпало из окончательного кода, поскольку TcxGridDbTableView изначально умеет делать некоторые вещи, которые в GridEh реализовывались в пользовательском коде.
Резюмируя вышесказанное скажу, процесс замены грида не столько трудоемок, сколько кропотлив. Но с парой серьезных “затыков” столкнуться все же пришлось. Об этом в следующем посте.
Другие статьи серии:
Редизайн интерфейса приложения. #0
Редизайн интерфейса приложения. #1
Редизайн интерфейса приложения. #3
Редизайн интерфейса приложения. #4
Редизайн интерфейса приложения. #5
Редизайн интерфейса приложения. #6
Редизайн интерфейса приложения. #7
Редизайн интерфейса приложения. #8
6 комментариев: Редизайн интерфейса приложения. #2
Оставить комментарий
>К слову, на мой взгляд по соотношению цена/функционал GridEh – все таки оптимальное решение.
При всём уважение к Вам Александр, не согласен этим утверждением. В своей практике был вынужден использовать EhLib4 (с пятым опыта не было) и DevEx6. В тех формах где EhLib гриды мне всё время приходилось писать что то связное с сортировкой (серверной, потомучто с лок. была беда), с фильтрациями (В квантум гриде свой буфер поэтому там этих проб. изначально нет, в Eh это перекладывается на компоненты доступа), с прорисовкой картинок, экспортом в эксель с цветами, и т.д. В итоги в нек. формах бизнес логика занимала меньше чем эта “дребидень” , по кол. строк кода. Не я конечно не хочу сказать в сторону EhLib что-то плохое, это очень! качественный компонент. Но если взять з/п программиста и сколько квантум грид сэкономит время и сил, то могу сказать точно что 400$ окупятся быстро (а в моей ситуации в течение месяца)
То же самое можно сказать и относительно PivotGrid (OLAP), если их сравнивать со стандартным ДивижионКубом (геморою слишком много)
Возможно, Вы и правы. Конечно все зависит от уровня приложения.
PivotGrid это, безусловно, мощнейший инструмент.
Сортировка, фильтрация… ну как-то же делал я это раньше руками…
С другой стороны, EhLib почти бесплатен. Стоит символически. Я получил на партнерке с блога каких-то денег и сразу себе купил пятый. Согласен, после cxGrid – не то. Согласен, devExpress стоит своих денег. Но для проекта с низким и даже средним бюджетом я cxGrid не куплю.
Я удивлен. Какой код вам приходилось писать, связанный с фильтрацией и сортировкой? В EhLib ведь достаточно подключить к проекту модуль, ответственный за сортировку и фильтрацию. Ну и еще возможно нужно прописывать origin-ы у полей. Но это не строки кода, тем более не огромное количество строк кода.
По моему (давно дело было) серверная сортировка и данные из Х.П. тянулись, подключаемые модули не помогали. IBE локальную не поддерживают
EhLib5 – Всё таки хорошая вещь относительно 4. Автор хорошо потрудился.
Есть один момент в EhLib которого нет DevEx – возможность фильтрации в дереве, в cxTreeList я пробывал делать анологич. функциональность через фильт. Датасета но потом просил эту идею гемора много.
Да. Мне тоже понравилось… Конечно, не совсем все очевидно… Документацию и примеры приходится читать/смотреть от корки до корки. Но возможности широкие. Сейчас как раз ковыряюсь с пятерочкой, можно сказать, исключительно из любопытства. Таки, нравится…