Новая система валидации отчетов в FastReport VCL

17.04.2026

В технической поддержке нас часто просили добавить функционал для автоматической проверки отчетов, и вот в релизе 2026.2.0 мы это сделали. В меню «Файл» в дизайнере отчетов появились пункты «Валидировать» (Validate) и «Настройки правил валидации» (Validation Rule Settings). Теперь можно не только проверять отчеты, но и управлять набором правилам, включая собственные.

В этой статье мы расскажем, как работает проверка отчетов, как её настроить, как писать собственные правила на примерах и поделимся интересными нововведениями.

Термины

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

Валидация — это проверка корректности построения отчета и соответствия его заданным правилам без его непосредственного построения. Осуществляется валидация путем последовательного применения к отчету набора заранее определенных правил.

Правило (Rule) — это отдельная функция проверки, выполняемая в процессе валидации отчета. Валидатор хранит набор правил. Правило может быть выключено или включено. При валидации запускаются только включенные правила. В процессе выполнения правило может отправлять множество сообщений.

Сообщение — это запись, которую правило формирует в ходе проверки отчета. Сообщение содержит информацию об обнаруженной проблеме, включая уровень критичности, текстовое описание и реакцию на двойное нажатие.

Как проверять отчеты в дизайнере

Валидация отчета выполняется при выборе в меню пункта «Валидировать» (Validate) или при нажатии комбинации клавиш Shift+F9. Также валидацию отчета можно привязать к сохранению или построению отчета. Это можно настроить в меню «Вид-Настройки…» (View-Options) на вкладке «Валидация» (Validation).

Флажок «Автоматическая валидация» (Automatic validation) — разрешает автоматический запуск проверки отчета при построении или сохранении отчета.

Настройка «Ошибка при уровне от» (Validation fails if severity is at least) определяет, от какого уровня ошибок считать валидацию неуспешной. Возможные значения: «Подсказка» (Hint), «Предупреждение» (Warning), «Ошибка» (Error).

Если вы выберете «Предупреждение», то валидация будет считаться неудачной, если при проверке обнаружится хотя бы одно предупреждение или ошибка. По умолчанию установлено значение «Ошибка».

Последние две настройки управляют действиями с отчетами, провалившими валидацию при сохранении или построении. Можно разрешить действие, уведомить пользователя или запретить его.

Настройка списка правил

В меню «Настройки правил валидации» (Validation rule settings) можно настроить набор правил, применяемых к отчету. Это окно выглядит следующим образом:

В левом списке «Правила по умолчанию» (Default rules) находятся встроенные правила. Правый список «Пользовательские правила» (Custom rules) предназначен для правил, созданных пользователем под конкретные задачи. При этом такое разделение условно: пользователь может поместить свои правила и в список правил по умолчанию.

Флажки под списками позволяют сразу установить или снять отметки у всех элементов списка. Флажок «Запускать проверку при сохранении» (Run validation on save) позволяет запускать валидацию при закрытии окна настроек правил по нажатию кнопки ОК.

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

Список правил по умолчанию

По умолчанию доступны следующие правила:

IntersectingTest — обнаруживает наложения компонентов отчета. В некоторых случаях это может быть сделано намеренно, но для табличных экспортов такие наложения могут вызвать сложности. Поэтому рекомендуем оставлять это правило включенным при использовании табличных экспортов.
PrepareScript — проверяет скрипт отчета. Сейчас проверка ограничивается компиляцией скрипта.
ComponentValidation_IsEmpty — находит пустые компоненты, не связанные с источниками данных. Иногда такие компоненты заполняются в скрипте, поэтому их наличие не всегда ошибка.
ComponentValidation_Properties — проверяет правильность установки свойств компонентов. Например, правило проверяет наличие непривязанных дочерних бэндов (Child Bands) и синтаксис выражений в свойствах.
ComponentValidation_Expressions — проверяет корректность выражений в компонентах, вычисляя их значения. По умолчанию отключено.
DatasetsValidation — проверяет правильность настройки датасетов отчета. По умолчанию отключено.

Обратите внимание, что список правил может быть дополнен в будущем.

Валидация отчетов из Демоцентра

Попробуем запустить валидацию отчета. Учтите: она будет считаться неуспешной, если появятся предупреждения и более серьезные ошибки (если вы забыли, как это делается, смотрите раздел «Как проверять отчеты в дизайнере»).

Возьмем отчет 1.fr3 из Демоцентра (DemoCenter) и начнем валидацию:

Валидация отчета завершилась неудачно. Правило IntersectingTest выявило пять предупреждений. Это было ожидаемо, так как пустой MemoView используется для заливки фона четных строк.

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

Отладочный вывод через DebugLn

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

Как это можно использовать? В скрипте отчета используйте новую функцию — DebugLn. Вызовите ее с параметром строкового типа. Значение параметра при выполнении отчета появится в окне «Messages» вместе с меткой времени. Давайте посмотрим на примере.

Откройте в «FastReport Demo» любой отчет, например, 1.fr3. Создайте несколько событий у компонентов и в коде обработчика события вызовите DebugLn() с именем события. Запустите отчет, и в окне Messages вы увидите следующую информацию:

Мы надеемся, что эта функция поможет вам более эффективно отлаживать отчеты.

Как написать свое правило

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

TfrxValidationRule — базовый класс для правил отчета. Для работы с классом необходимо переопределить абстрактный метод Validate (AReport: TfrxReport).

TfrxValidationPageRule — класс, рассчитанный на постраничную валидацию отчета. В потомках необходимо переопределить метод ValidatePage — этот метод будет вызван для каждой страницы отчета.

TfrxValidationComponentRule — класс, рассчитанный на поэлементную валидацию отчета. В классе необходимо переопределить метод ValidateComponent — этот метод будет вызван для проверки каждого компонента отчета.

Для уведомления о том, что найдена ошибка валидации, в базовом классе TfrxValidationRule предусмотрен метод.

procedure DoMessage(ASeverity: TfrxValidationSeverity; 
const AText: string; 
ADoubleClickData: TObject = nil);

Метод отправляет зарегистрированным получателям сообщение с информацией об ошибке. Рассмотрим параметры этого метода подробнее.

ASeverity: TfrxValidationSeverity — этот параметр определяет тип ошибки, передаваемый в уведомлении валидации, и может принимать значения vsHint, vsWarning, vsError.
const AText: string; — строка с сообщением об ошибке.
ADoubleClickData: TObject = nil — параметр, отвечающий за действия при двойном клике.

Рассмотрим немного подробнее третий параметр ADoubleClickData. В данный момент туда можно послать только экземпляр класса TfrxDoubleClickSetSelectionData. Может быть расширено в дальнейшем.

Данный класс имеет следующие поля:

ComponentName: string — имя компонента, при проверке которого произошла ошибка валидации.
PropName: string; имя свойства компонента, при проверке которого произошла ошибка валидации.
SelStart: TPoint — начальная позиция кода с ошибкой в редакторе кода.
SelEnd: TPoint — конечная позиция кода с ошибкой в редакторе кода.

Для правильной обработки есть 3 варианта заполнения данного объекта:

Только ComponentName — при двойном щелчке произойдет переход к компоненту.
ComponentName + PropName — свойство будет выделено в инспекторе объектов. Возможна активация и вложенных свойств — это вы сможете увидеть в примере ниже.
SelStart + SelEnd — при двойном щелчке мышью по сообщению произойдет переход в редактор кода с выделением текста.

После отправки сообщения об ошибке валидации объект отвечающий за двойной клик необходимо удалить. Для использования правила написанный класс необходимо зарегистрировать. Это делается вызовом следующего кода:

frxValidationSettings.RegisterRule(ABucket: TfrxRuleBucket; 
ARuleClass: TfrxValidationRuleClass; AActive: Boolean = True);

Объект frxValidationSettings определен в модуле TfrxValidator. Это синглтон (Singleton) для хранения правил валидации.

Параметры вызова следующие:

ABucket: TfrxRuleBucket — служит для определения значения правила (системное или созданное пользователем). Может принимать значения rbCustom, rbDefault.
ARuleClass: TfrxValidationRuleClass — класс созданного правила.
AActive: Boolean — устанавливает активно ли правило по умолчанию (далее это можно изменить в диалоге настройки правил).

На основе изложенного попробуем сформулировать правило валидации отчета. Допустим, мы создаем отчеты для корпорации, где все тексты должны быть оформлены в корпоративных цветах - черном и красном. Использование других цветов считается ошибкой. Рамки надписей также должны быть черными или красными, а фон белым. Так как мы проверяем отдельные компоненты, то нам подходит для наследования класс TfrxValidationComponentRule.

Объявление нашего класса правила выглядит так:

type
 TCorporateRule = class(TfrxValidationComponentRule)
 private
 procedure SendMessage(AComponent: TFrxComponent; APropertyName, AText:string);
 public
 procedure ValidateComponent(AComponent: TfrxComponent); override;
 class function GetName: string; override;
 end;

Также требуется переопределить метод GetName для возвращения имени правила. Реализация методов:

class function TCorporateRule.GetName: string;
begin
 Result := 'Corporate_Colors';
end;
 
 
procedure TCorporateRule.SendMessage(AComponent: TFrxComponent;
 APropertyName: string);
var
 LSelData: TfrxDoubleClickSetSelectionData;
begin
 LSelData := TfrxDoubleClickSetSelectionData.Create;
 try
 LSelData.ComponentName := AComponent.Name;
 LSelData.PropName := APropertyName;
 DoMessage(vsError, AComponent.Name + ': Invalid color of property ' + APropertyName, LSelData);
 finally
 LSelData.Free;
 end;
end;
 
 
procedure TCorporateRule.ValidateComponent(AComponent: TfrxComponent);
var LMemo: TfrxMemoView;
 function CheckColors(AValue: TColor): Boolean;
 begin
 Result := (AValue = clBlack) or (AValue = clRed) or (AValue = clWhite) or (AValue = clNone) ;
 end;
begin
 if not (AComponent is TfrxMemoView) then Exit;
 LMemo := TfrxMemoView(AComponent);
 if not CheckColors(LMemo.Font.Color) then
 SendMessage(LMemo, 'Font.Color');
 if (not CheckColors(LMemo.Frame.TopLine.Color)) and (ftTop in LMemo.Frame.Typ) then
 SendMessage(LMemo, 'Frame.TopLine.Color');
 if not CheckColors(LMemo.Frame.BottomLine.Color) and (ftBottom in LMemo.Frame.Typ) then
 SendMessage(LMemo, 'Frame.BottomLine.Color');
 if not CheckColors(LMemo.Frame.LeftLine.Color) and (ftLeft in LMemo.Frame.Typ) then
 SendMessage(LMemo, 'Frame.LeftLine.Color');
 if not CheckColors(LMemo.Frame.RightLine.Color) and (ftRight in LMemo.Frame.Typ) then
 SendMessage(LMemo, 'Frame.RightLine.Color');
 if not CheckColors(LMemo.Color) then
 SendMessage(LMemo, 'Color');
end;

И регистрируем правило:

initialization
 frxValidationSettings.RegisterRule(rbCustom, TCorporateRule);

Запускаем наше приложение, открываем дизайнер отчетов и проверяем список правил.

Теперь давайте проверим с помощью нашего правила какой-либо отчет. Например, отчет из Демоцентра (DemoCenter) под названием 1.fr3.

В логе проверки видно, что правило срабатывает. При двойном клике на ошибку мы сразу переходим к компоненту с неправильным цветом. В инспекторе объектов нужное свойство выделено.

Валидация вне дизайнера

Средствами FastReport реализована проверка отчетов только в дизайнере. Однако, если такие проверки необходимы и в других случаях, пользователь может реализовать их самостоятельно. То есть можно валидировать сотни отчётов по нажатию одной кнопки. Это можно реализовать следующим образом.

Сначала необходимо создать класс валидатора TfrxValidator.
Далее ввести список правил с помощью метода frxValidationSettings. ApplySettings(AValidator: TfrxValidator).
Если необходимо использовать не все доступные правила, а только определенные, то необходимо у объекта-валидатора самостоятельно заполнить списки DefaultRules и CustomRules объектами-правилами (пример реализации находится в frxValidationSettings. ApplySettings).
С помощью метода TfrxValidator.AddListener(const AListener: IfrxValidationListener) мы добавляем получателей сообщений об ошибках валидации.
Затем запускаем метод TfrxValidator.Validate(AReport: TfrxReport) для проверки отчета.

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

Как видим, валидация отчетов — это несложно и очень полезно. Мы будем рады предложениям по созданию новых правил.

Delphi FastReport VCL Дизайнер Кастомизация

21 апреля 2026