Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

заNILить форму после Close;

Страницы: < 1 2 3 4 5 6 7 8 9 10 >
ничтожная козявка © (2008-08-21 12:37:00)
В некой dll есть функция, показывающая форму. Перед созданием формы, она проверяет ее на NIL:
if not Assigned(Form1) then Form1 := TForm1.Create(AOwner);

также требуется, что бы после закрытия (Close) форма была уничтожена:
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction); begin ... Action := caFree; ... end;

ВОПРОС: как сделать так, чтоб она была не только уничтожена, но и переменная Form1 приняла значение NIL. Т.к. поскольку эта переменная не NIL, при повторной попытке создать форму, ее конструктор
if not Assigned(Form1) then Form1 := TForm1.Create(AOwner);
не вызывается, и в последствии сыпятся AV.

DVM (2008-08-22 14:50:00) [121]
А в SysInit сколько глобальных переменнных. Их тоже в классы загонять?

DVM (2008-08-22 14:44:00) [122]

> Leonid Troyanovsky © (22.08.08 14:24) [64]

> Это уже не переменные, а константы.

Но формально, они в разделе var, а не const. Да и нельзя присвоить именно константе из раздела const значение уже во время выполнения программы.

Выходит, с одной стороны:

> > А ООП и глобальные константы совместимы?
>
> Вполне.

Но с другой:

> ведь глобальные переменные и ООП несовместимы.

Anatoly Podgoretsky (2008-08-22 14:38:00) [123]
> @!!ex (22.08.2008 14:15:03) [63]

В [1] нет никакой проверки существования формы.

Anatoly Podgoretsky (2008-08-22 14:36:00) [124]
> DVM (22.08.2008 14:12:02) [62]

Надо стремиться, см. выше

Anatoly Podgoretsky (2008-08-22 14:35:00) [125]
> DVM (22.08.2008 14:11:01) [61]

Нет, есть исключения - глобальные переменные Дельфи, Application и Screen
Из собственных только две - DataModele и MainForm - но это по принципам работы, раньше Дельфи иначе работала, можно было и без CreateForm писать.

Leonid Troyanovsky (2008-08-22 14:24:00) [126]

> DVM © (22.08.08 14:03) [58]

> Там есть множество переменных которые один единственный
> раз должны быть проинициализированы при старте программы
> и в дальнейшем менять ся во время выполнения программы не
> могут. Версия Windows например.

Это уже не переменные, а константы.
Проинициализировать что-либо при старте - это еще тот бином Ньютона.

> Да, но тогда тот же sysutils будет намертво приклеен к TApplication,
> а этот самый TApplication нужен бывает не везде и не всегда.

Это вопрос проектирования.
А Application мог бы пригодиться хоть и в консольном приложении.

> А ООП и глобальные константы совместимы?

Вполне.

--
Regards, LVT.

@!!ex (2008-08-22 14:15:00) [127]
> Если Вы с этим не согласны, то докажите, что я не прав.
> Только не надо слов, надо конкретно - Вы же этого хотели?
> Вот и напишите конкретный работающий пример проверки существования
> формы с помощью кода [1].

А я написал, конкретный, работающий пример еще в [1] написал. Автор даже проверил и отписался, что да, действительно работает:

> @!!ex
> Ок, спасибо! Это работает.

DVM (2008-08-22 14:12:00) [128]

> Anatoly Podgoretsky © (22.08.08 14:11) [60]

> да и сам Дельфи далек от классического ООП

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

Anatoly Podgoretsky (2008-08-22 14:11:00) [129]
> DVM (22.08.2008 14:03:58) [58]

Не совместимы, да и сам Дельфи далек от классического ООП

DVM (2008-08-22 14:11:00) [130]

> Anatoly Podgoretsky © (22.08.08 14:06) [59]

Вы тоже категорически против глобальных переменных?

Я лично, не вижу ничего зазорного, если, скажем в каком то модуле программы будет глобальная переменная MyVar, которая в блоке initialization модуля получает значение из некоторой функции MyVar := MyVARFunc(); Почему я не использую функцию MyVARFunc напрямую вместо переменной? Вызов MyVARFunc может занимать много времени и ресурсов, например.

Другое дело, когда заводятся глобальные переменные для форм. Это мне не нравится.

Anatoly Podgoretsky (2008-08-22 14:06:00) [131]
> DVM (22.08.2008 13:37:55) [55]

Русский программист и даже русский человек в состоянии оправдать что угодно.

DVM (2008-08-22 14:03:00) [132]

> Ну, и что там упрощенного, читабельного и лаконичного?

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

> Сделай все эти переменные, скажем, полями TApplication,
> и будет всем хорошо.

Да, но тогда тот же sysutils будет намертво приклеен к TApplication, а этот самый TApplication нужен бывает не везде и не всегда.

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

А ООП и глобальные константы совместимы? Да и не ООП единым...

Leonid Troyanovsky (2008-08-22 13:55:00) [133]

> DVM © (22.08.08 13:37) [55]

> и лаконичной. Взгляните на модуль SysUtils, к примеру.

Ну, и что там упрощенного, читабельного и лаконичного?

Сделай все эти переменные, скажем, полями TApplication,
и будет всем хорошо.

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

--
Regards, LVT.

Leonid Troyanovsky (2008-08-22 13:49:00) [134]

> Юрий Зотов © (22.08.08 13:34) [54]

> 1. Плагинная архитектура.
> 2. Обновление по сети.
> 3. Повторное использование кода в других приложениях.

Необходимость первого нуждается в отдельном обосновании.

А, в остальном, изволь: пусть это будет, например,
web service & client.

--
Regards, LVT.

DVM (2008-08-22 13:37:00) [135]

> Leonid Troyanovsky © (21.08.08 15:15) [19]

> 1. глобальные переменные - MD,

Это, мягко говоря, чушь. Глобальная переменная, будучи применена в нужное время и в нужном месте нисколько не ухудшает, а наоборот упрощает программу и делает ее более читабельной и лаконичной. Взгляните на модуль SysUtils, к примеру.

Юрий Зотов (2008-08-22 13:34:00) [136]
> Приведи три причины необходимости использования
> DLL with BPL with EXE vs EXE

1. Плагинная архитектура.
2. Обновление по сети.
3. Повторное использование кода в других приложениях.

Leonid Troyanovsky (2008-08-22 13:22:00) [137]

> Loginov Dmitry © (21.08.08 21:05) [41]

> Application, Screen - тоже глобальные переменные. Долой
> их?

Я уже не один раз высказывался по этому поводу, не вижу
смысла повторяться.

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

Мои соболезнования.

> если DLL и ЕХЕ скопилены с пакетами, то очень даже не MD.

Приведи три причины необходимости использования
DLL with BPL with EXE vs EXE, тогда и обсудим кто MD.

--
Regards, LVT.

Юрий Зотов (2008-08-22 12:40:00) [138]
> @!!ex © (22.08.08 07:33) [48]

> Что не нравится, можно поконкретнее?

Можно. Давайте действительно конкретно. Поскольку иначе, как вдруг выяснилось, не получается.

Конкретность № 1.

Я утверждаю, что Ваш код в [1] для сабжа совершенно бесполезен, так как проконтролировать существование формы не позволяет.

Если Вы с этим не согласны, то докажите, что я не прав. Только не надо слов, надо конкретно - Вы же этогохотели? Вот и напишите конкретный работающий пример проверки существования формы с помощью кода [1].

После этого сможем перейти к другим конкретностям. Если, конечно, до них вообще дойдет дело.

Anatoly Podgoretsky (2008-08-22 10:52:00) [139]
Не надо контролировать по содержимому глобальной переменной, пример я привел выше, переменная равна nil а форма есть и точно также наоборот.
Есть же гарантирование средство Screen.Forms

ничтожная козявка (2008-08-22 10:48:00) [140]

> @!!ex © (22.08.08 07:33) [48]
> Вы не могли бы процитировать сообщение, где автор на это
> указывает?

форма действительно должна быть одна, на самом деле, хотя я об этом прямо не говорил..
глоб. переменная Form1 у меня одна и перед созданием формы я и произвожу ее проверку на nil чтобы избежать дублей.
синглтону тут действительно самое место, но что-то лень:)) получилось почти тоже самое, только я единственность объекта контролирую не в его конструкторе а за пределами класса вобще, во внешнем коде.. короче я тут рогаткой обошелся :)) за универсальностью буду в других, более важных вещах гоняться:))

Страницы: < 1 2 3 4 5 6 7 8 9 10 >

Наверх

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