Как уничтожить TDatamodule

[ViktorXP]

Цитата RuSA @ 14.07.11, 12:51

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

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

Добавлено 14.07.11, 13:05
пс. на моей практике я несколько подобных случаев (которых предлагаеш ты) и справлял на нотификацию. я бы не лез (ибо старые проекты лучше не трогать пока они работают) но контейнеров создавалось несколько и каждый создавал для себя дата модуль (при этом глобальная переменная юзалась одна. что тоже являлось ошибкой ибо они повисали в воздухе), и при уничтожении одного из модулей все остальные контейнеры не могли уже работать ибо переменная nil.
посему повторюсь что нотификация спасет мир. еще ни разу не подводила.

[Fr0sT]

function DataModule1: TDataModule1;
procedure DestroyDataModule1;
 
implementation
 
var dmDataModule1: TDataModule1;
 
function DataModule1: TDataModule1;
begin
  if dmDataModule1 = nil then
    dmDataModule1 := TDataModule1.Create;
  Result := dmDataModule1;
end;
 
procedure DestroyDataModule1;
begin
  FreeAndNil(dmDataModule1);
end;

А вообще я продолжаю не понимать смысл затеи. Для освобождения памяти достаточно деактивировать все объекты модуля, зачем его сам-то сносить?

[ViktorXP]

Цитата Fr0sT @ 14.07.11, 13:15

Для освобождения памяти достаточно деактивировать все объекты модуля, зачем его сам-то сносить?

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

[leo]

Цитата RuSA @ 14.07.11, 12:51

а) если освобождаемая переменная X уже nil, то FreeAndNil выполнится без ошибок, а Free даст "NULL Pointer",

Нет, т.к. Free делает проверку if Self <> nil then Destroy;

Цитата RuSA @ 14.07.11, 12:51

В исходном варианте проблема была в том, что в момент вызова
...
Datamodule2 была <> nil, но сам экземпляр уже был освобождён. Так что вариант с обнулением в деструкторе вылечил бы это, если бы тут использовалось FreeAndNil

Ничего бы он не вылечил, т.к. проблема не в обнулении, а в том, что объект DataModule2 сделан слугой фиг знает скольки господ - и TBaseConnector, и Application, и как глобальная переменная ва-аще доступна всем желающим, в частности шаловливым ручонкам г-на cyberovskij Если бы DataModule2 удалялся один раз в деструкторе TBaseConnector до завершения приложения (например в FormDestroy или раньше), то никакой-бы ошибки тут не было и без обнуления. Но раз ошибка есть, то либо удаление TBaseConnector прописано где-то в finalization и срабатывает после Application.Free, либо автор где-то понатыкал еще несколько удалений. Как бы то ни было, а подход корявый - раз собрался "прятать" компоненты работы с базой, то 1) незачем глобальную переменную создавать, 2) незачем сюда вообще приплетать Application - создавай объект, через TDataModule1.Create(nil) и сам отвечай за его удаление (ну или наоборот - если не нужно удалять "досрочно", то пусть сидит в Application до "конца жизни")

Сообщение отредактировано: leo - 14.07.11, 15:17

[RuSA]

Цитата ViktorXP @ 14.07.11, 12:56

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

здесь предлагает автор - ему надо освободить объект datamodule2.
Для этого предлагается вызвать элементарное FreeAndNil(DataModule2) в нужном месте проги.
+ страховка внутри destroy, для очитски АВТОМАТИЧЕКИ созданной Delphi переменной.
И всё.

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

[leo]

Цитата RuSA @ 14.07.11, 15:18

здесь предлагает автор - ему надо освободить объект datamodule2

Еще раз - если автор освобождает объект datamodule2 только в деструкторе TBaseConnector и ДО того как этот объект будет уничтожен Application, то никакое обнуление не нужно. Если же ПОСЛЕ, то - "лопух", и никакое обнуление тут тоже не поможет. Если же где-то удаляет "ручками" через явный вызов datamodule.free, то тоже "лопух" - не подумал, к чему это может привести

Сообщение отредактировано: leo - 14.07.11, 15:33

[cyberovskij]

Цитата leo @ 14.07.11, 15:32

Цитата RuSA @ 14.07.11, 15:18

здесь предлагает автор - ему надо освободить объект datamodule2

Еще раз - если автор освобождает объект datamodule2 только в деструкторе TBaseConnector и ДО того как этот объект будет уничтожен Application, то никакое обнуление не нужно. Если же ПОСЛЕ, то - "лопух", и никакое обнуление тут тоже не поможет. Если же где-то удаляет "ручками" через явный вызов datamodule.free, то тоже "лопух" - не подумал, к чему это может привести

Уже автор давно не освобождает datamodule2. Я принял во внимание топик #5 от 05772 и решил все дата_объекты создавать и уничтожать в модуле baseconnector; всем спасибо за отписку.

Добавлено 14.07.11, 16:16

Цитата leo @ 14.07.11, 15:13

шаловливым ручонкам г-на cyberovskij

Ага, видели бы мои ручища

[leo]

Цитата cyberovskij @ 14.07.11, 16:13

Уже автор давно не освобождает datamodule2. Я принял во внимание топик #5 от 05772 и решил все дата_объекты создавать и уничтожать в модуле baseconnector; всем спасибо за отписку.

Молодец, только, боюсь, что ты так толком и не понял, что модуль с TDataModule ничем особым не отличается от обычного модуля и лишь упрощает создание и настройку компонентов БД - все остальное в твоих руках. Убираешь дата-модуль из автосоздания, удаляешь переменную var DataModule2:TDataModule2, добавляешь описание и код твоего класса TBaseConnector и сохраняешь модуль под именем baseconnector. Ну и ес-но вместо Application.CreateForm юзаешь FDm:=TDataModule2.Create(nil), где FDm:TDataModule2 - приватное поле твоего класса. У-се, работай наздоровье с дата_объектами через свой класс - ни Application, никакие другие шаловливые "ручища" их не удалят
Хотя, если хочешь по совету 05772 все своими "ручищами" создавать, то ради бога

Сообщение отредактировано: leo - 14.07.11, 17:03