Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как определить, что объект уже не жив... [D6, Win2k, WinXP]


Страницы:   1 2 3

aleshap ©   (2006-01-16 10:45:00) 

Добрый день!
Думаю, что вопрос простой... только не могу найти на него ответ...

Ситуация такова
var F:TForm

begin
F:=myForm;
...  
при некоторый условиях происходит myForm.Free
...
Как определить, что F - это уже несуществующий  объект?
end;

Заранее Спасибо!!!


Leonid Troyanovsky   (2006-01-25 14:32:00) [1]


> PVOzerski ©   (25.01.06 13:38) [53]

> массив или список? В конце концов, OOP - не религия. А список
> можно и инкапсулированный использовать - хоть наследника TList.


Такой список уже есть - Screen.Forms, содержит только живые формы.
Т.е., ничего и отслеживать не надо.

Хотя, я почему-то думал что данная дискуссия в "Начинающих", а так бы,
конечно, промолчал, бо в оной ветке уже все разжевано и пошло по кругу.

--
Regards, LVT.


Fay   (2006-01-25 14:15:00) [2]

2 Рустем ©   (25.01.06 13:50) [54]

Вам очевидно, что класс форма знает про некую конкретную f?


Рустем   (2006-01-25 13:50:00) [3]


> aleshap

См. [18]!


PVOzerski   (2006-01-25 13:38:00) [4]

2Leonid Troyanovsky ©   (25.01.06 12:18) [52]
Дык это же простенький пример :) Естественно, для N объектов это будет список из N флажков. Чем тут плох глобальный динамический массив или список? В конце концов, OOP - не религия. А список можно и инкапсулированный использовать - хоть наследника TList.


Leonid Troyanovsky   (2006-01-25 12:18:00) [5]


> PVOzerski ©   (25.01.06 11:26) [51]

> var
>  Form1Lives: boolean = false;
>
> constructor TForm1.Create(AOwner: TComponent);
> begin
>  Form1Lives := true;
>  inherited;
> end;


Млин, ну сколько про это говорено.
Ну, не положено ООПрограммистам плодить глобальные переменные.
Особенно в таких случаях, когда объектов может быть более одного.

--
Regards, LVT.


PVOzerski   (2006-01-25 11:26:00) [6]

Что значит "при некоторых условиях"? Если эти "некоторые условия" находятся в рамках тобой же написанного кода, почему нельзя заменить все "критические" Free на FreeAndNil. Если же нет, вставь, например, в обработчики событий OnCreate и OnDestroy "регистрацию" и "разрегистрацию" объекта. В более универсальном случае, не только для форм, можно переопределить конструктор и деструктор. Естественно, конструктор и деструктор базового объекта должны быть виртуальными или динамическими. Формы этому требованию удовлетворяют тоже.

unit Unit1;

interface

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs;

type
 TForm1 = class(TForm)
 private
   { Private declarations }
 public
   { Public declarations }
   constructor Create(AOwner: TComponent); override;
   destructor Destroy; override;
 end;

var
 Form1: TForm1;

implementation

{$R *.dfm}

var
 Form1Lives: boolean = false;

constructor TForm1.Create(AOwner: TComponent);
begin
 Form1Lives := true;
 inherited;
end;

destructor TForm1.Destroy;
begin
 inherited;
 Form1Lives := false;
end;

end.


eugie   (2006-01-25 06:33:00) [7]

Способ 1: объявлять переменную типа SomeVariable:T[SomeObject] с областью видимости, которая обеспечивала бы обращение к ней из необходимых модулей. Перед созданием и после уничтожения объекта SomeVariable присваивать nil и проверять на это значение.
Способ 2: вести глобальный список объектов, например TStringList, в который добавлять objects - указатели на определенные объекты.


Zeqfreed   (2006-01-17 10:31:00) [8]

evvcom ©   (17.01.06 9:07) [48]
Перед тем как я отправил свой пост [46] я прочитал всю ветку, даже посты про чьих-то мужей, которые фактически существуют, но не настоящие. Если у Вас есть какое-то мнение относительно моего поста, то выскажете его, пожалуйста, не выдвигая мне каких бы то ни было голословных обвинений. На текущий момент я не вижу причин, почему решение высказанное в [18] нельзя считать удовлетворительным. Разве что механизм уведомлений, предложенный в [47] является более элегантным решением.


evvcom   (2006-01-17 09:07:00) [9]


> А что касается, собственно сабжа — ответ в [18] считаю вполне
> удовлетворительным.

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


Leonid Troyanovsky   (2006-01-16 18:13:00) [10]


> Zeqfreed ©   (16.01.06 17:53) [46]
> Assigned равнозначно сравнению с nil. А что касается, собственно
> сабжа — ответ в [18] считаю вполне удовлетворительным.


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

А использование глобальных переменных, вообще, MD.

--
Regards, LVT.


Zeqfreed   (2006-01-16 17:53:00) [11]

Assigned равнозначно сравнению с nil. А что касается, собственно сабжа — ответ в [18] считаю вполне удовлетворительным.


Плохиш   (2006-01-16 17:24:00) [12]


> tesseract ©   (16.01.06 17:17) [43]
> то он может указывать на мусор области памяти, что выявит Assigned.

А заглянуть в реализацию Assigned, слабо?

> тогда достаточно проверить объект на nil.

Читать [40] до полного прояснения ;-)


Fay   (2006-01-16 17:20:00) [13]

2 tesseract ©   (16.01.06 17:17) [43]
> А почему просто не попробовать Assigned?
procedure TForm1.Button1Click(Sender: TObject);
const
 a : array[Boolean] of String = ('No', 'Yes');
var
 sl : TStringList;
begin
 sl := TStringList.Create;
 sl.Free;
 ShowMessage(a[Assigned(sl)])
end;


tesseract   (2006-01-16 17:17:00) [14]

А почему просто не попробовать Assigned?
Даже если указатель на объект освобождён, то он может указывать на мусор области памяти, что выявит Assigned.
Или при освобождении объекта использовать FreeAndNil или
Object.free;
Object:=nil;
тогда достаточно проверить объект на nil.


evvcom   (2006-01-16 12:20:00) [15]


> Странно, что Вы не предположили, что объект Screen уничтожен

Ну я все же не садист! Вдруг он кому-то все же нужен.

> или что TForm -- это вовсе не класс формы, а какой-то другой
> класс с таким именем.

А это уже крутой мазохизм.
P.S. Ко мне можно на ты.


Fay   (2006-01-16 12:11:00) [16]

2 begin...end ©   (16.01.06 12:05) [39]
Это уже лишнее.


Плохиш   (2006-01-16 12:07:00) [17]


> TUser ©   (16.01.06 11:59) [38]
> Используй FreeAndNil

И чем он в этом случае поможет? ;-)

> var F:TForm
>
> begin
> F:= myForm;
> ...  
> при некоторый условиях происходит myForm.Free


begin...end   (2006-01-16 12:05:00) [18]

> evvcom ©   (16.01.06 11:40) [34]

Странно, что Вы не предположили, что объект Screen уничтожен, или что TForm -- это вовсе не класс формы, а какой-то другой класс с таким именем.


TUser   (2006-01-16 11:59:00) [19]

Используй FreeAndNil


evvcom   (2006-01-16 11:49:00) [20]


> Из вопроса и из [20] не следует, что объект - наследник
> TForm

Да я это давно понял, но даже если и следовало бы, то аргумент в [34]. Т.е. в общем случае даже для TForm [1].


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо