Блог Александра Божко
Архивы
Рубрики
Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Так получилось, что рассказывать о переводе приложения с 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 я пробывал делать анологич. функциональность через фильт. Датасета но потом просил эту идею гемора много.

    • Да. Мне тоже понравилось… Конечно, не совсем все очевидно… Документацию и примеры приходится читать/смотреть от корки до корки. Но возможности широкие. Сейчас как раз ковыряюсь с пятерочкой, можно сказать, исключительно из любопытства. Таки, нравится…

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика