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

← →
@!!ex © (2008-08-21 20:52) [40]

> 1. Чему будет равно поле формы после ее уничтожения?

Согласен, лучше обнулять на уничтодение, а не на закрытие.

> 1. Не нужно усложнять то, что можно сделать просто.

а нет там усложнения. А вот когда выяснится, что нужно две TForm1 будет СТОЛЬКО граблей...
Мы все таки с использованием ООП пишем, или только вид делаем?

← →
Loginov Dmitry © (2008-08-21 21:05) [41]

> "единичность формы"(если именно ее преследует автор) можно
> будет сделать "такой же" глобальной переменной, только например
> Булевого типа.... и делов.

Круто! Избавляемся от одной глобальной переменной, добавляем другую :)

> ога, я понял, потому что Self и Form1 это две большие разницы
> и заниливание одного из этих указателей ничего не даст.

По значению то же самое, но не по адресу.

> TForm1(Sender) := nil;
> end;
> не спасет?

обнулится локальная переменная, или регистр, а дальше что?

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

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

> 2. формы в длл - MD.

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

> Что бы определить существует форма или нет, глобальных переменных
> для этого не надо, а надо использовать Screen.Forms

зачем усложнять и вносить заведомые тормоза? Если форма не модальная и может существовать не более чем в одном экземпляре, то глобальная переменная, автоматически предлагаемая Delphi, имхо, самое оно! Для модальных же форм смысла в каких-либо глобальных переменных гораздо меньше, почти всегда достаточно
with TForm.Create() do try ShowModal; finally Free; end;
Для дочених форм MDI глобальные переменные и вовсе недопустимы.

← →
Юрий Зотов © (2008-08-21 21:09) [42]

> @!!ex © (21.08.08 20:52) [40]

> а нет там усложнения.

Точно нет? А я-то на Ваш код глядел-глядел - и никак не мог сообразить:

1. На фига там нужно поле типа "указатель на указатель", а не просто "указатель"? (мелочь, но все же).

2. Каким образом это поле позволяет проверить существование формы? Никаким.

> А вот когда выяснится, что нужно две TForm1 будет СТОЛЬКО граблей

3. Еще раз: каким образом Ваш код от этих граблей спасает? Никаким.

4. Не выяснится. Сабж читайте. Весь смысл в том и есть, что вторая форма не допускается.

> Мы все таки с использованием ООП пишем, или только вид делаем?

5. Мы вообще пишем, или только вид делаем? Вы понимаете, что Ваш код ничего не дает и неверен в самом своем принципе?

← →
Anatoly Podgoretsky © (2008-08-21 22:10) [43]

> @!!ex (21.08.2008 20:52:40) [40]

А лучше не обнулять, а если обнулять, то не нулем.

← →
McSimm © (2008-08-22 00:42) [44]

> А лучше не обнулять, а если обнулять, то не нулем.

так память же перевыделится кому-нибудь ?
на вероятностях проверка получается.

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

Уже забыл, кажется именно так реализован какой-то рабочий класс в VCL (TPrinter?, TClipboard?)

← →
{RASkov} © (2008-08-22 01:30) [45]

> [41] Loginov Dmitry © (21.08.08 21:05)
> Круто! Избавляемся от одной глобальной переменной, добавляем другую :)

Вся разница в том, что ее "нилить" не нужно.... т.е. безболезненно ее можно "занилить"(сбросить в False) например на OnClose....
Так что, ничего это и не круто, а тоже самое почти, может только чуть проще... :)

← →
{RASkov} © (2008-08-22 02:03) [46]

> Уже забыл, кажется именно так реализован какой-то рабочий класс в VCL (TPrinter?, TClipboard?)

Оба. Printer и Clipboard - это по сути не переменные, а функции... А реализация их проста:

var FClipboard: TClipboard; function Clipboard: TClipboard; begin if FClipboard = nil then FClipboard := TClipboard.Create; Result := FClipboard; end;

Принтер точно так же....

← →
Юрий Зотов © (2008-08-22 06:13) [47]

Если поставить супернадежность и принципы ООП самоцелью, то класс формы надо просто сделать синглтоном - и всех дел.
implementation var _Instance: TObject; class function TForm1.NewInstance: TObject; begin if _Instance = nil then _Instance := inherited NewInstance; Result := _Instance; end; procedure TForm1.FreeInstance; begin inherited; _Instance := nil; end;
Только всегда ли нужна стрельба из пушек? Иногда бывает вполне достаточно и рогатки.

← →
@!!ex © (2008-08-22 07:33) [48]

> 1. На фига там нужно поле типа "указатель на указатель",
> а не просто "указатель"? (мелочь, но все же).

А нафига там нужен указатель??
Нам надо ссылку обнулить или где?

> 2. Каким образом это поле позволяет проверить существование
> формы? Никаким.
>
> > А вот когда выяснится, что нужно две TForm1 будет СТОЛЬКО
> граблей

Если форма существует, то Form1 не nil? Если не существует, то nil. Какие еще варианты развития событий?

> 4. Не выяснится. Сабж читайте. Весь смысл в том и есть,
> что вторая форма не допускается.

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

> 5. Мы вообще пишем, или только вид делаем? Вы понимаете,
> что Ваш код ничего не дает и неверен в самом своем принципе?

Позволяет обнулить ссылки указывающие на объект?
В примере только одну, если ввести массив, то все.
Что не нравится, можно поконкретнее?

← →
Anatoly Podgoretsky © (2008-08-22 07:50) [49]

> Если форма существует, то Form1 не nil? Если не существует,
> то nil. Какие еще варианты развития событий?

Form1 := nil

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

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

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

← →
Anatoly Podgoretsky © (2008-08-22 10:52) [51]

Не надо контролировать по содержимому глобальной переменной, пример я привел выше, переменная равна nil а форма есть и точно также наоборот.
Есть же гарантирование средство Screen.Forms

← →
Юрий Зотов © (2008-08-22 12:40) [52]

> @!!ex © (22.08.08 07:33) [48]

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

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

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

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

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

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

← →
Leonid Troyanovsky © (2008-08-22 13:22) [53]

> 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 13:34) [54]

> Приведи три причины необходимости использования
> DLL with BPL with EXE vs EXE

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

← →
DVM © (2008-08-22 13:37) [55]

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

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

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

← →
Leonid Troyanovsky © (2008-08-22 13:49) [56]

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

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

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

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

--
Regards, LVT.

← →
Leonid Troyanovsky © (2008-08-22 13:55) [57]

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

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

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

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

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

--
Regards, LVT.

← →
DVM © (2008-08-22 14:03) [58]

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

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

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

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

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

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

← →
Anatoly Podgoretsky © (2008-08-22 14:06) [59]

> DVM (22.08.2008 13:37:55) [55]

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

← →
Anatoly Podgoretsky © (2008-08-22 14:11) [60]

> DVM (22.08.2008 14:03:58) [58]

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

← →
DVM © (2008-08-22 14:11) [61]

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

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

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

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

← →
DVM © (2008-08-22 14:12) [62]

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

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

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

← →
@!!ex © (2008-08-22 14:15) [63]

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

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

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

← →
Leonid Troyanovsky © (2008-08-22 14:24) [64]

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

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

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

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

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

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

Вполне.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2008-08-22 14:35) [65]

> DVM (22.08.2008 14:11:01) [61]

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

← →
Anatoly Podgoretsky © (2008-08-22 14:36) [66]

> DVM (22.08.2008 14:12:02) [62]

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

← →
Anatoly Podgoretsky © (2008-08-22 14:38) [67]

> @!!ex (22.08.2008 14:15:03) [63]

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

← →
DVM © (2008-08-22 14:44) [68]

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

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

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

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

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

Но с другой:

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

> DVM © (22.08.08 14:44) [68]

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

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

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

> Но с другой:

Как не крути, переменные отличаются от констант.

--
Regards, LVT.

А в SysInit сколько глобальных переменнных. Их тоже в классы загонять?

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

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

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

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

> DVM © (22.08.08 14:50) [70]

> А в SysInit сколько глобальных переменнных. Их тоже в классы
> загонять?

Чего их гнать, раз уж они уже случились.
Речь-то шла о собс-ручных переменных.

--
Regards, LVT.

> Leonid Troyanovsky © (22.08.08 13:49) [56]

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

Необходимость второго и третьего - тоже. Таким обоснованием (причем, железобетонным) может служить, например, ТЗ.

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

Что тоже нуждается в обосновании. Причем, не менее.

PS
Леонид, как известно, многие (если не все) задачи можно решить разными способами. Естественно, выбор того или иного решения ВСЕГДА должен быть обоснован. Проектируя архитектуру (структуру кода и т.п.) будущей программы, конечно, НИКОГДА не следует забывать о необходимости обоснования выбранного решения, но точно так же и НИКОГДА не следует априори отметать то или иное из прочих возможных решений.

PPS
Пресловутые "советы" предназначены для совсем уж начинающих и хороши лишь тем, что позволяют НАЧИНАЮЩИМ уберечься от распространенных ошибок. Но не стоит превращать их в догмы - иначе они станут столь же вредны, сколь и полезны. Программист просто должен понимать, что, как и зачем он делает, чем это хорошо и плохо, какие могут быть подводные камни и как их не допустить - и т.д.

> @!!ex © (22.08.08 14:15) [63]

Как уже справедливо заметил Анатолий, в примере [1] нет никакой проверки существования формы - то есть, нет никакого решения сабжа вообще.

Добавьте к примеру [1] ЛЮБУЮ такую проверку - и я ДОКАЖУ Вам (причем, вполне конкретно, как Вы и хотели), что работать она НЕ будет. Потому что никакая проверка, основанная на коде [1] работать не может уже в самом ПРИНЦИПЕ этого кода.

Вы хотели конкретики? ОК, я жду ее. И теперь уже от Вас просто так не остану, поверьте. Извините, но сами напросились.

Итак - либо к примеру [1] Вы добавляете конкретный, неопровержимый и работающий код проверки существования формы, либо признаете (явным или неявным образом - неважно), что код в [1] для такой проверки не дает ровно ничего.

После чего сможем перейти к другим "конкретностям" в коде [1]. Они там тоже имеются.

То, что уже было написано в [1] и немного измененный.
TForm1 = class public FormLinkPointer:^TForm1; end; .... Form1:TForm; Form1:=TForm.Create(); Form1.FormLinkPointer:=@Form1; procedure TForm1.FormClose(...); begin Action := caFree; end; procedure TForm1.OnDestroy(...); begin FormLinkPointer^:=nil; end;

Собственно проверка:
if Form1<>nil then //Значит существует else //Значит не существует

Вот тоже самое в коде:
http://www.mediafire.com/?btmj4ydyxgn

> Добавьте к примеру [1] ЛЮБУЮ такую проверку - и я ДОКАЖУ
> Вам (причем, вполне конкретно, как Вы и хотели), что работать
> она НЕ будет. Потому что никакая проверка, основанная на
> коде [1] работать не может уже в самом ПРИНЦИПЕ этого кода

И ведь работает... У меня в компиляторе ошибка, да?

С нетерпением жду доказательства неработоспособности работающего кода. :))

> @!!ex (22.08.2008 16:01:15) [75]

Я уже писал

Form1 := nil;
Form1 := AnyValue;

> [78] Anatoly Podgoretsky © (22.08.08 16:22)

Так это применимо и к коду ЮЗ.
Давайте тогда вообще флаги не использовать? Они же сломатся могут...
реальный пример, когда Form1 ghbcdfbdf.n rfrjt nj ytrjhhtrnyjt pyfxtybt - vj;yj&

>>Когда Form1 присваиваЮт какое то некорректное значение - можно?

заNILить форму после Close; Найти похожие ветки