Описание ModelMaker Code eXplorer

Обещанный обзор ModelMaker Code eXplorer.

Сегодня я расскажу об одном эксперте для Delphi, способным фантастически упростить рефакторинг. Разработан этот эксперт компанией ModelMakerTools.  У ModelMakerTools есть 2 продукта, которые часто путают:

1. ModelMaker - инструмент для работы с UML в Delphi.
2. ModelMaker Code eXplorer (MMX) - набор инструментов для рефакторинга. Существуют версии для Delphi и для Visual Studio. В этом посте я расскажу о версии для Delphi.

MMX интегрируется в Delphi 5 - 7, Delphi 2005 - 2010 и Delphi XE. Т.е. вы получаете удобный инструмент для рефакторинга практически в любых версиях Delphi. И этот инструмент удобнее стандартных мастеров для рефакторинга, встроенных в Delphi.

Почти все функции которые я здесь описываю, доступны в MMX начиная с версии 5.1. Текущая версия – 9.0. Для снимков экрана я использовал версию 8.

Скажу сразу, ModelMaker Code eXplorer – платный продукт. Новая лицензия стоит 99 евро. И купить его можно только через ShareIt.

Но на сайте доступна trial версия, которая работает в течение 30 дней без каких-либо ограничений. Более того каждое обновление продлевает срок trial-а. (раньше было так, как сейчас не знаю).

Ложка дёгтя: после окончания 30-дней триала, MMX может вызывать Access Violation-ы при работе с IDE. Например при нажатии Ctrl+Shift+вверх или вниз. Или в других случаях. В общем, если ваша IDE внезапно начала сыпать ошибками, проверьте, не закончился ли испытательный период у MMX. Чтобы убедится, Для этого достаточно открыть окно Code Explorer. Если trial окончен, там будет показано соответствующее сообщение. Такие AV в IDE, это побочный эффект от защиты от взломов trial-а и способный серьёзно потрепать нервы. Поэтому предупреждаю о нём сразу. В остальном, это прекрасный и удобный инструмент для Delphi программиста.

Скриншоты MMX на официальном сайте. История изменений. На сайте продукта доступны видеоролики, демонстрирующих функционал MMX. Это что касается официальной документации. А тех, кому интересны личные впечатления, прошу пожаловать под кат.

Что мне особенно нравится в MMX - так это то, что каждая функция там работает именно так как заявлено, и часто учитывает мельчайшие нюансы, такие как, например, местонахождение курсора. Так, например при вставке кода из буфера обмена, в зависимости от того, где находился курсор в момент вызова функции, код будет превращён либо в процедуру, либо в метод класса.

Это наверное самый большой пост у меня в блоге. Более 2000 слов, 13 тысяч знаков без пробелов. И картинки. Надеюсь, что для вас он окажется полезным.

Читать дальше..

Переход на юникод 3. С Ehlib 3.6 на Ehlib 5.x

Продолжаю делиться опытом по переводу своего проекта на юникод. В этот раз я остановлюсь на обновлении библиотеки Ehlib с версии 3.6 на версию 5.2. Как я уже говорил, я проводил обновление стараясь сделать так, чтобы большая часть кода могла компилироваться и в Delphi 6 и в Delphi 2010.

С Ehlib-ом было всё просто. Мы без раздумий решили покупать обновление, тем более что версия 5.х содержит в себе массу отличных фич. Т.е. конечно, порядка ради мы с коллегами обсудили вариант обновить самим. Но решили, что новые фичи Ehlib-а, нам будут более чем полезны. Тем более, что по соотношению цена/качество/удобство - это самый лучший DbGrid для Delphi. Ещё рассматривался вариант с покупкой DevExpress, но высокая цена и необходимость переделывать те наработки, что уже сделаны для Ehlib-а убедили нас пока не связываться с TcxGrid.

Настройка Delphi для работы разными версиями библиотек.

Пятая версия Ehlib была распакована в отдельную папку Ehlib5. Также, в виде отдельной папки она была внесена в систему контроля версий. Папку с исходниками Ehlib 3.6 (предположим, что она называлась Ehlib3) я не трогал, ведь мне необходимо собирать проект и с 3й и с 5й версией библиотеки.

На данном этапе вся работа проходила в Delphi 6. Следующим пунктом встал вопрос, а как объяснить Delphi,  какую из версий Ehlib-а использовать? Для исходного кода проблема разрешилась с помощью введения в свой код новой директивы компилятора WANT_EHLIB5.

Но что же делать с dcu-файлами, и с настройками путей до исходных файлов Ehlib? Ведь и Ehlib 3 и Ehlib 5 содержат юниты с одинаковыми именами. Как объяснить Delphi, что когда я собираю проект с директивой WANT_EHLIB5 она должна искать исходники в папке Ehlib5, а когда без этой директивы, то исходники должны браться из папки Ehlib3?

Идеального решения я не нашёл.

Читать дальше..

Описание CnPack IDE Wizards часть 20: Формы настройки мастеров. Скриншоты.

Немного отвлекусь от темы перехода с Delphi 7 на юникод, для продолжения описания CnWizards.

Это двадцатая запись в серии "Эксперты для Delphi: описание CnPack Wizards”. В прошлый раз я начал описание настроек CnPack Wizards, точнее просто опубликовал скриншоты основных форм настройки с кратким описанием. Этот пост будет сделан в таком же духе. Я не буду вдаваться в детали и просто покажу как выглядят все формы настройки. Здесь будут скриншоты и ничего более. Правда в отличие от предыдущего поста, здесь будет не три картинки, а штук тридцать.

В прошлый раз меня спрашивали, какой смысл, публиковать только скриншоты с парой строк описания. Так вот для меня смысл есть и состоит он в том, чтобы подготовить скриншоты для описания, а также сделать мой блог более популярным для поисковиков. Ведь есть люди, которых интересует чтобы их находили по фразе няня для ребенка Одесса, а меня вот интересует чтобы мой блог находили по фразе "Описание экспертов для Delphi". А регулярные публикации по теме - лучшее средство в таком случае. А текста здесь мало, потому что на мой взгляд здесь всё видно по скриншотам. Тем более что почти все из них сделаны на русскоязычной версии CnWizards.

(осторожно, траффик! под катом много картинок.)

Читать дальше..

Переход на юникод 2. План перехода и сторонние библиотеки.

Как я уже писал, я выбрал для перехода стратегию, требующую того, чтобы код приложения собирался как в Delphi 6, так и в Delphi 2010. Эта стратегия была выбрана как наиболее универсальная и позволяющая в любой момент переключиться на стратегию 3 и продолжить работу с копией кода программы заточенной только под одну юникодную версию Delphi.

Исследование ситуации

Итак, начинать надо с пакетов. Без них всё-равно не собрать программу. Первым делом я запустил Lazy Delphi Builder, просканировал папки с исходниками и стал пробовать компилировать каждый из пакетов, поочерёдно выписывая в блокнот имена пакетов, отказывавшихся собираться на Delphi 2010. Получился первый список проблемных пакетов. Конечно, на самом деле я не компилировал каждый из пакетов. Ведь понятно, что если пакет X не скомпилировался, то и все пакеты, которые зависят от пакета X также не компилироваться не будут.

Большая часть самописных библиотек зависела от сторонних библиотек, так что переход на юникод надо было начинать со сторонних либ.

Общий план перехода

1. Обновить все библиотеки от сторонних производителей.
2. Добиться, чтобы программа стабильно работала на Delphi 6 после завершения работы над первым пунктом.
3. Если сторонние пакеты больше не поддерживаются, перевести их на юникод собственноручно или заменить аналогами поддерживающими юникод.
4. Добиться, чтобы программа компилировалась и стабильно работала после завершения работы над третьим пунктом.
5. Сделать необходимые изменения в коде самописных пакетов, чтобы они могли собираться как в Delphi 6 так и в Delphi 2010 и продолжали стабильно работать в Delphi 6.
6. Сделать необходимые изменения в коде приложения, чтобы его можно было собрать и в Delphi 6 и в Delphi 2010.
7. После сборки в Delphi 2010 протестировать работу, и начать исправлять ошибки связанные с переходом на Delphi 2010. При каждом исправлении проверять, что приложение собирается и работает и 6й и в 2010й версии Delphi.

Сторонние библиотеки

Из сторонних библиотек у меня использовались:

Читать дальше..

Переход на юникод 1: Поиск стратегии.

Обещанная статья о переводе большой программы с Delphi 6 на Delphi 2010 (для Delphi 2009 и Delphi XE (2011), ситуация будет аналогичной). Материала получилось довольно много, поэтому я разобью его на несколько постов.

Дано

Большое приложение, с большой базой данных и большой историей. Приложение, которое начали разрабатывать ещё на Delphi 3, потом портировали на Delphi 6. Теперь надо ввести поддержку юникода, и собрать в Delphi 2010. Приложение использует кучу пакетов как самописных, так и от сторонних производителей. Проект большой, комментариев в коде практически нет. Юнит-тесты написаны только для очень маленькой части кода общих библиотек.

Что надо получить?

Работающую версию программы с поддержкой юникода для D2010. Из-за большого числа клиентов, крайне желательно, чтобы обновлению программы (включая базу данных) с неюникодной версии на юникодную происходило по возможности безболезненно. В идеале сделать так, чтобы с одной и той же базой данных можно было работать как из уникодной версии программы так и из Ansi-версии.

Необходимо поддерживать и развивать существующую версию (на Delphi 6), исправляя найденные баги и расширяя функционал. А баги будут на сто процентов. Всё-таки баги в программах появляются также ожидаемо как глисты у собак летом.

Стратегии перехода

Стратегии для перехода на Юникод:

1. Сделать так, чтобы один и тот же код мог собираться как в Delphi 6, так и в Delphi 2010 и чтобы программа работала стабильно и без ошибок.
2. Начать проект с нуля только на Delphi 2010, частями перенося код из версии для D6.
3. Сделать копию стабильной версии проекта и вести работу по переходу на юникод на копии, оставляя нетронутой стабильную версию для Delphi 6.

Плюсы и минусы стратегий

Читать дальше..