Мне очень нравятся Build Events в Delphi. Это когда с проектом можно связать некую команду (например, cmd-скрипт), которая будет выполняться перед сборкой (или после сборки) приложения. Будь то по F9, либо при внешней сборке с помощью MSBuild. Мне это нужно для актуализации автогенерируемого кода, используемого проектом.
На днях занимался оптимизацией Prebuild-события, постоянно правил свой cmd-скрипт, и мне очень быстро надоело переключаться между Delphi и Notepad++ (в котором редактировал скрипт). Немного покопавшись в ToolsApi, у меня получилось сделать подсветку синтаксиса для CMD/BAT-файлов.
Выглядит это так:

Это в меню Tools Options. Как это выглядит в самом редакторе – см. ниже.
Пока сделал на скорую руку (осторожно, черновой код!), исходник доступен тут: https://github.com/delphinotes/Useful/tree/master/CMDHighlighter
Устанавливается так:

1. Открываем CMDHighlighter.dproj.
2. В опциях проекта указываем суффикс – в зависимости от версии Delphi (210 – это для Delphi XE7), см. последний столбец http://docwiki.embarcadero.com/RADStudio/XE7/en/Compiler_Versions
   
3. В Project Manager’е делаем Install.
   Если не захочет устанавливаться, то можно удалить dproj-файл, открыть dpk-файл и сделать как в пункте 2.
4. Подсветка установлена, теперь необходимо связать её с cmd-файлами. Рекомендую делать так:
   • File Close All
   • Tools Options –> Editor Options Source Options –> New…Ввести CMD/BAT, нажать OK
   • В поле Extensions ввести cmd;bat
   • Установить флажок Use syntax highlight и выбрать CMD/BAT Highlighter в комбобоксе:
     
   • Остальные флажки и значения – по вкусу.

А вот как выглядит кусочек моего Prebuild-скрипта:

Спасибо за внимание 🙂

Читать на сайте автора.

Эта заметка является продолжением к заметкам Стиль оформления кода. Вместо вступления, Настройки окружения и Регистр букв.

(Я планировал немного другой порядок публикаций, но отсутствие времени (ну т.е. лень) не даёт мне возможности навести порядок в некоторых промежуточных моментах.)

Копирайт

Авторские права исходных текстов, разрабатываемых внутри компании, принадлежат самой компании и лицензируются согласно правилам лицензирования, установленных внутри компании.

Следует разделять два уровня доступа к исходным текстам:

• внутри компании (при создании и сопровождении проектов);
• вне компании (при публикации в открытый доступ, либо при передаче третьим лицам).

Размещение копирайта в исходном тексте модулей в первом случае не нужно (это трудоёмко и снижает читаемость), но является необходимым во втором случае. Это делается непосредственно перед публикацией/передачей (либо при размещении в системе контроля версий) автоматизировано, необходимый текст генерируется по шаблону и вставляется в каждый исходный файл в самом начале в виде комментария. Кроме копирайта, такой комментарий может содержать информацию о лицензионном соглашении, номер версии (или ревизии) файла, историю изменений и другую информацию.

Начало

В зависимости от своего типа, файл начинается с одного из зарезервированных слов: package, program, library или unit. Следом за ним, через один пробел, следует имя файла (без расширения) с точкой с запятой на конце. Например:

unit UnitName;

В случае отсутствия копирайта, такая строка должна быть самой первой в файле, либо отстоять через одну пустую строку после копирайта.

Это требование исходит из соображений: в случае последовательного просмотра файлов из «продвинутых» файловых менеджеров — имя файла всегда находится на одном и том же уровне от начала файла, а в случае отсутствия копирайта переход к имени модуля осуществляется всего в три клавиши: Ctrl+Home, Ctrl+Right.

Если файл имеет неявную для компилятора связь с другим текстовым файлом, который обрабатывается до (либо после) компиляции, то следующей строкой может идти комментарий вида:

// UnitName.xml

Это удобно для быстрого перехода к редактированию указанного в комментарии файла по сочетанию Ctrl+Enter.

Информацию о версии, даты создания и модификации, а также историю изменений можно вести в отдельном текстовом файле, сославшись на него аналогичным образом:

// UnitName.hst

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

Далее может следовать многострочный комментарий с описанием предназначения файла и нюансы его использования. Текст комментария обрамляется либо фигурными скобками { и }, либо парой (* и *) и отстоит от левого края на один отступ (см. пример). Однако вместо такого комментария рекомендуется использовать отдельный текстовый файл и его имя размещать в простом комментарии, например:

// UnitName.txt

После всех комментариев следуют директивы компилятора, относящиеся ко всему исходному тексту модуля. См. также: определения условной компиляции.

Секция uses

Зарезервированное слово uses занимает отдельную строку. Объявляемые далее модули группируются по принадлежности, а внутри группы располагаются в порядке использования (см. пример).

В секции implementation слово uses следует располагать после директив, относящихся ко всему разделу реализации модуля (см. пример).

Эта рекомендация следует из соображения, что секция uses может быть многострочной и имеет тенденцию к расширению. Съезжающие вниз директивы отвлекают внимание.

Секция interface

Все объявления из интерфейсной секции модуля доступны другим модулям и становятся глобальными. Поэтому секция interface должна быть максимально компактной и лаконичной, и не должна содержать объявления, которые не могут или не должны использоваться за пределами модуля. Это в особенности касается переменных, создаваемых автоматически при создании новых форм/фрейм:

var
  Form1: TForm1;

Такие переменные (за исключением единичных случаев) следует сразу удалять.

В случае, когда модуль является служебным и его код исполняется во время инициализации и/или финализации, интерфейсная часть модуля может быть пустой.

Секция implementation

Это секция реализации модуля. Она может быть пустой, либо содержать только код инициализации и/или финализации — это секции initialization и finalization.

Конец модуля

Модуль заканчивается ключевым словом end с точкой на конце. Размещение любого текста после последнего end не запрещено, но приводит к выдаче компилятором предупреждения, потому считается крайне не желательным.

Директивы компилятора

Директивы компилятора, относящиеся ко всему исходному тексту модуля, располагаются перед интерфейсной частью между ключевыми словами unit и interface. Директивы, относящиеся к секции реализации модуля, располагаются сразу за словом implementation. Остальные директивы могут располагаться в тексте в любом месте, согласно правилам форматирования кода. (Также см. пример.)

Порядок объявления методов

В VCL принято сначала объявлять конструктор класса, затем деструктор, затем все методы в алфавитном порядке. Это удобно, когда реализуемый класс получается большим (содержит большое количество методов) и является законченным и готовым к использованию. Однако алфавитный порядок следования методов неудобен при чтении кода и при его сопровождении. Для удобства рекомендуется подход, описанный ниже.

При объявлении методов (в секции interface) сначала объявляются обработчики методов. Обработчики группируются по принципу их принадлежности — сначала обработчики формы (фрейма), затем обработчики остальных компонентов (Action’ов, кнопок, грида и т.п.). Внутри группы рекомендуется использовать порядок в соответствии порядка использования обработчиков в RunTime, т.е. сначала идут OnCreate, затем OnShow (или OnInit, OnLoadData, OnLoadState), а затем OnClose, OnDestroy (OnSaveState, OnSaveData, OnDone).

«Парные» методы можно располагать рядом, т.е. обработчики OnCreate/OnDestroy, OnShow/OnClose и т.п. Это удобно для контроля парности действий, выполняемых в таких обработчиках.

Для обработчиков событий Action’ов — сначала OnUpdate, затем OnExecute. Это положение вытекает из таких моментов:

• Action.Execute всегда внутри себя сначала вызывает OnUpdate, а затем OnExecute, следование обработчиков в коде логично сопоставить с порядком вызова обработчиков. (Кстати, это документированная особенность TAction — обработчик OnExecute не будет вызван, если в OnUpdate свойство Action.Enabled сбрасывается в False.)
• Читая код OnExecute часто приходится на какой-то момент переключаться на код обработчика OnUpdate, для глаз это удобнее делать, когда расстояние между обработчиками (ключевыми словами procedure) фиксированное. Как правило, код обработчика OnUpdate занимает одну-две строки, а код OnExecute может занимать и более 10 строк. Расположение обработчиков в порядке OnUpdate/OnExecute повышает скорость читаемости кода.

Остальные методы (которые не являются обработчиками событий) также рекомендуется группировать по смыслу и располагать в порядке их использования.

При реализации методов (в секции implementation), рекомендуется соблюдать те же принципы, что и при объявлении, единственным отличием может быть тот факт, что некая группа методов в разделе объявления может быть разделена на части по области видимости.

Пример

unit Example;
// Example.hst

(*
  Необязательное описание предназначения файла и нюансы его использования.
  Вместо данного описания рекомендуется давать понятные имена файлам, чтобы предназначение
  было самим-собой разумеющимся, а нюансы использования вытекали автоматически из интерфейсной части модуля.
  А в случае "раздувания" такого комментария его рекомендуется вынести в отдельный текстовый файл.
*)

{$I Common.inc}
{$ALIGN ON}
{$MINENUMSIZE 4}

interface

uses
  // Delphi units
  SysUtils, DateUtils, Windows, Classes, Forms,
  // My units
  MyUnit1, MyUnit2;

type
  TExample = class(TForm)
    procedure FormLocalize(Sender: TObject);
    // OnCreate, OnDestroy, OnShow, OnClose ...
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  end;

implementation

{$R *.dfm}

uses
  MyUnitA, MyUnitB;

{ TExample }

constructor TExample.Create(AOwner: TComponent);
begin
  inherited;
  // do something
end;

destructor TExample.Destroy;
begin
  // do something
  inherited;
end;

procedure TExample.FormLocalize(Sender: TObject);
begin
  {$include *.mui.inc}
end;

// OnCreate, OnDestroy, OnShow, OnClose ...

end.

Читать на сайте автора.

Эта заметка является продолжением к предыдущей.

Программное окружение, в котором работает программист, а точнее его настройки – сугубо индивидуальная вещь. Но есть несколько моментов, которые прямо или косвенно влияют на результат. Ниже приведены рекомендации, которые будут частью будущего документа; на них будут ссылаться другие разделы документа.

Настройки окружения

Дизайн пользовательского интерфейса должен быть максимально однообразным. Для достижения этого при разработке форм необходимо выполнение следующих требований:

• масштабирование текста в ОС Windows должно быть установлено в 100%;
• тема оформления ОС Windows должна быть классической (с использованием шрифта Tahoma по умолчанию).

Масштабирование текста

При разработке форм в Delphi учитывается текущее разрешение экрана, а точнее параметр PPI — логическое количество точек на дюйм. Во время исполнения приложения, при создании формы, если текущее значение PPI не совпадает с тем, которое было сохранено в dfm-файле, происходит масштабирование.

К сожалению в VCL механизм масштабирования содержит ошибки. Подробно об этом описано здесь.

На уровне BaseForms.pas большая часть проблем исправлена, но новый механизм масштабирования требует, чтобы все dfm-файлы проекта разрабатывались в едином PPI. На текущий момент это значение должно равняться 96.

Это настройка операционной системы, называется «масштабирование текста». Чтобы PPI равнялось 96, масштабирование должно быть установлено в 100%.

Тема оформления

В разных темах оформления используются разные шрифты и разные размеры неклиентских элементов диалоговых окон (строка заголовка, граница окна, полосы прокрутки и другие). Это влияет на внешний вид разрабатываемых в Delphi форм (на разницу между значениями ClientWidth (ClientHeight) и Width (Height) формы, а также на высоту некоторых компонентов типа TEdit и TCombobox, для которых высота определяется по размеру шрифта). Использование разных тем оформления может привести к случайному/лишнему изменению свойств формы и её компонентов.

Классическая тема и шрифт Tahoma являются наиболее распространёнными в корпоративной среде, диалоговые окна и пользовательский интерфейс логичнее всего разрабатывать именно для них.

Настройки IDE

Настройки IDE Delphi — главное меню Tools Options. Эту настройку достаточно выполнить один раз, сразу после установки Delphi.

VCL Designer

Environment Options VCL Designer

Use designer guidelines необходимо сбросить.

Snap to grid – установить.

Grid size необходимо выставить именно в 4 и все компоненты располагать по сетке (Snap to grid) потому, что в Windows есть масштабирование. К числам, кратным 4, хорошо применяются стандартные масштабы текста – 75%, 125%, 150% и выше.

New forms as text – для того, чтобы новые dfm-файлы сохранялись в виде текстовых файлов; это необходимо при сравнении двух разных версий одного файла.

Auto create forms & data modules – выключено, т.к. формы создаются в Run-Time по мере необходимости.

Embedded designer – установить, настройка преследует две цели: а) избежать лишнего/случайного изменения положения формы (свойства Left и Top) в dfm-файл (когда программист просто подвинул форму, чтобы не мешала); б) вообще не сохранять эти свойства в dfm-файл (реализовано на уровне BaseForms – когда значения равны нулю, они не сохраняются).

Editor Options

Editor Options Display

Right margin = 120 – значение 80 использовалось на старых мониторах; сейчас подавляющее большинство мониторов – широкоформатные, значение 120 является наиболее оптимальным как для чтения кода, так и по использованию экранного пространства. Именно это значение используется как максимально допустимая ширина строки в данном документе.

Остальные параметры на данной вкладке являются рекомендуемыми, но необязательными.

Formatter Options

Formatter Delphi Indentation

Formatter Delphi Spaces

Formatter Delphi Line breaks

Formatter Delphi Capitalization

Formatter Delphi Align

 

DDevExtensions

DDevExtensions – это расширение для IDE Delphi, скачивается и устанавливается отдельно со страницы: http://andy.jgknet.de/blog/ide-tools/ddevextensions/.

После установки необходимо выполнить настройку: IDE Delphi — главное меню Tools DDevExtensions Options.

Extended IDE Settings:

• Disable alpha-sort class completion
  Эту настройку необходимо включить, т.к. данный документ вместо автоматического расположения методов в алфавитном порядке обязует это делать осмысленно — см. Порядок объявления методов

Form Designer:

• Active
  Включить
• Set TLabel.Margins.Bottom to zero
  Включить
• Do not store the Explicit* properties into the DFM
  Включить

Пара комментариев

Первые два скриншота сделаны в Delphi 2010. От использования Delphi 7 мы отказались.

Скриншоты настроек форматировщика кода – из Delphi XE7, здесь он уже более-менее прилично работает, хотя часто промахивается, когда пытаешься отформатировать только выделенный кусок кода.

Насчёт масштабирования – на самом деле не важно, какое оно выставлено в системе. Важно, чтобы у всех членов команды оно было одинаковым (два момента: визуальное наследование и случайное/лишнее обновление dfm-файла). Есть ещё такой момент: определив его равным 100% я себе облегчаю задачу при описании правил создания пользовательских интерфейсов (grid size, размеры компонентов и расстояния между ними).

Читать на сайте автора.

Чуть больше года назад я писал об успешном переходе с Delphi 7 на Delphi 2010 приложений в нашей компании (Вот и мы перешли на Юникод).

В этой заметке кратенько опишу об особенностях перехода с Delphi 2010 на Delphi XE7.

Требования остались прежними – надо чтобы работало и там, и там. Впоследствии, возможно, с отказом от использования Delphi 2010. (От Delphi 7 мы уже отказались… ну за исключением совсем старых программ, которые не развиваются.)

Алгоритм тоже не претерпел сильных изменений – сначала обновление сторонних компонентов, затем обновление компонент и библиотек, которые уже не поддерживаются первоначальными разработчиками, затем обновление своих исходников.

Черновой переход – компиляция и запуск программ со случайным “прокликиванием” интерфейсов и без прогонки тестов – у меня занял всего несколько часов (менее одного рабочего дня). Тяжелее скучнее всего было делать замены такого плана:

  с DecimalSeparator на
  {$if CompilerVersion >= 24}FormatSettings.{$ifend}DecimalSeparator

потому что надо было:

• найти номер версии Delphi, где это произошло в RTL (в данном случае это XE3 – произошёл отказ аж от 20 штук глобальных переменных в пользу всего одной);
• таких подобных мест очень много – кроме групповой замены я себе ещё помечал, что не плохо бы пересмотреть код.

Удивила так называемая нормализация типов TPoint, TRect, TSize (в XE2). В одном месте даже написал такой хелпер (хелпер оказался лишним, всё решилось проще, путём переименования локальной переменной).

Ну и некоторые другие редкие мелочи, типа UNIT_PTR или LRESULT.

Переход пока черновой, ради спортивного интереса. Скорость полной сборки приложений можно сказать, что осталась прежней – я проводил по несколько измерений после разных сценариев использования IDE – разница в среднем на 0.4 сек дольше, чем в Delphi 2010 (редко бывало и наоборот). Размер исполняемого exe-файла, получаемого на выходе – в XE7 в среднем на 2.5 мегабайта больше (в Release-сборке, проверял на семи проектах с размером экзешников от 6 до 19 мегабайт).

При этом, стоит отметить как плюс в сторону IDE – Find Declaration (он же Ctrl+Click) стал стабильно добираться до цели, в Delphi 2010 же он через какое-то время просто отваливается.

Сейчас в XE7 пока достаёт только то, что при открытии проекта IDE сразу загружает все модули,объявленные в dpr-файле. И из-за того, что компоненты в IDE я пока не устанавливал, Delphi выдаёт десятки окон вида:

Приходится зажимать Escape и ждать… ну секунд 10, терпимо.

Пока я доволен.

P.S.: не спешно (ну очень не спешно) готовлю обновление для BaseForms и dnSplitter. Ваши комментарии могут сыграть роль волшебного пендаля :с).

Читать на сайте автора.

Пробую Delphi XE7. Пока нравится. Поставил GExperts – очень уж я привык к сочетаниям Ctrl+Alt+Down и Ctrl+Alt+Up – переход к следующему/предыдущему объявлению идентификатора. CnPackWizards пока не вышел, но и без него вполне можно жить.
И тут вдруг бросилось в глаза, что у Object Inspector’а шрифт не такой, как везде… (везде – Tahoma 8, а тут – Segoe UI 9)
В GExperts вроде и была возможность менять шрифт инспектора, но почему-то пропала. Поэтому “накидал” на скорую руку пакет, исправляющий данную особенность, результат на картинке (было – стало):

Исходник пакета доступен на GitHub, или можно скачать zip-архив отсюда – в  папке ObjInspFntChngr. В модуле uObjInspFntChngr.pas через константы:

const
  PreferParentFont = True;
  PreferFontName = 'Tahoma';
  PreferFontSize = 8;

можно настроить шрифт по своему вкусу.

HINT: Возможно пакет поможет тем, у кого масштабирование текста в Windows больше 100%.

Для установки – открыть dproj-файл, правой кнопкой мыши в Project Manager’е – Install. Пакет можно использовать и в предыдущих версиях Delphi, для этого достаточно удалить dproj-файл и открыть пакет через dpk-файл.

Читать на сайте автора.