Проблема с изменением базового класса TDataModule в Delphi и неожиданным поведением дизайнера

Delphi , Базы данных , Модуль данных

Введение

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

Описание проблемы

Пользователь dan13l столкнулся со следующей ситуацией:

1. В проекте имеется несколько TDataModule, которые нужно изменить так, чтобы они наследовались от нового базового класса.
2. Базовый класс добавляет метод и некоторые данные, но не содержит публикуемых элементов (нет необходимости в DFM-файле).
3. После изменения наследования код компилируется и работает, но при открытии модуля данных в дизайнере Delphi обрабатывает его как форму, добавляя в DFM свойства формы (ClientHeight, ClientWidth и т.д.), что приводит к ошибкам времени выполнения.

Пример базового класса:

unit uBaseDataModule;

interface

uses
  System.Classes;

type
  TBaseDataModule = class(TDataModule)
  private
    FSomeList: TList;
  protected
    procedure SomeMethod;
  end;

implementation

[...]

end.

Пример класса-потомка:

unit fMainDataModule;

interface

uses
  System.SysUtils, System.Classes, uBaseDataModule;

type
  TMainDataModule = class(TBaseDataModule)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  MainDataModule: TMainDataModule;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.dfm}

end.

После открытия в дизайнере DFM-файл изменяется, добавляя свойства формы, что вызывает ошибки.

Почему это происходит?

Delphi ожидает, что для классов, производных от TDataModule, которые должны быть редактируемыми в дизайнере, базовый класс также должен иметь DFM-файл. Это отличается от поведения с формами (TForm), где можно создать базовый класс без DFM-файла.

Когда дизайнер не находит DFM-файл для базового класса, он по умолчанию обрабатывает компонент как форму, добавляя соответствующие свойства.

Решения проблемы

1. Создание DFM-файла для базового класса (рекомендуемое решение)

Самый простой и надежный способ - создать DFM-файл для базового класса, даже если он практически пустой:

1. Создайте новый модуль данных в IDE.
2. Измените свойство Name на BaseDataModule.
3. Сохраните модуль под нужным именем.
4. В классах-потомках измените ключевое слово object на inherited в DFM-файле.

Пример DFM для базового класса:

object BaseDataModule: TBaseDataModule
  OldCreateOrder = False
  Height = 0
  Width = 0
end

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

2. Использование интерфейсного класса (interposer class)

Альтернативное решение, предложенное Anders Melander, заключается в использовании интерфейсного класса для переопределения TDataModule:

unit Foo.Bar;

interface

uses
  Classes;

type
  TBaseDataModule = class(TDataModule)
  private
    FFoobar: integer;
  public
    property Foobar: integer read FFoobar write FFoobar;
  end;

implementation

end.

А в модуле-потомке:

unit Whatever;

uses
  Classes, etc. etc., ...
  Foo.Bar;

type
  // Интерфейсный класс
  TDataModule = TBaseDataModule;

// Ваш обычный модуль данных
type
  TMainDataModule = class(TDataModule)
  ...
  end;

Этот подход позволяет обойти проблему, так как дизайнер будет видеть TDataModule, но фактически класс будет наследоваться от вашего TBaseDataModule.

3. Редактирование DPROJ-файла (менее надежное решение)

PeterBelow предложил проверить узлы DCCReference Include в DPROJ-файле и сравнить их с обычными модулями данных. Однако, как отметил dan13l, этот метод не всегда работает, так как наследуемые и обычные модули данных могут выглядеть в DPROJ одинаково.

Почему эти решения работают?

1. DFM-файл для базового класса: Delphi ожидает полной цепочки наследования DFM-файлов для компонентов, редактируемых в дизайнере. Наличие DFM-файла для базового класса удовлетворяет это требование.

2. Интерфейсный класс: Этот подход "обманывает" дизайнер, заставляя его думать, что класс наследуется от стандартного TDataModule, в то время как фактически используется ваш базовый класс.

Рекомендации

1. Для простых случаев рекомендуется использовать первый метод с созданием DFM-файла для базового класса. Это наиболее "правильный" с точки зрения Delphi способ.

2. Для сложных сценариев, где создание DFM-файла невозможно или нежелательно, можно использовать интерфейсный класс.

3. Избегайте ручного редактирования DPROJ-файла, так как это может привести к нестабильности проекта.

Заключение

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

Создано по материалам из источника по ссылке.

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

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Модуль данных ::