client6aacТак вот вопрос: как занулить переменную формы после ее закрытия?

Удалить эту переменную вообще.
Она не нужна.

Реестр существующих окон держать в другом виде, например




Ну и не забывать оттуда удалять закрываемые формы.

P.S. именно такой реестр на самом деле редко практичен: он не позволяет открывать НЕСКОЛЬКО окон одного класса. Впрочем, как и переменная "frmMdiChildren1" не может содержать несколько указателей на несколько окон сразу.

А в реальности часто по другому. Например в браузере открыто несколько разных веб-страничек, в Excel открыто несколько разных файлов: класс один и тот же, а окон много: уникальный идентификатор окна состоит не только из класса, но и ещё каких-то данных.

goldmi45client6aac,




Или проще




http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Generics_Collections_TList_Contains.html

Но вообще привязывать реестр (реестры) открытых окон к TMainForm - стрёмная идея.
Потом если понадобиться распутать - то хрен распутаешь, спагетти зависимостей нарастёт.

goldmi45Arioch,

Зачем создавать то, что уже есть?

MDIChildren и MDIChildCount

1) лаконичнее. Одна строка - вызов стандартной функции TList<t>.Contains гораздо меньше, чем расписанный вами if с циклами. Следовательно, меньше шансов тупой ошибки.

2) гибче. Например, в дальнейшем нужно будет иметь несколько MDI-Parent окон. Или с MDI будет переход на что-то другое (табы, докающиеся плавающие окна, ...)

client6aacя не пойму как это все делать из БАЗОВОЙ формы:)

1) пробросить в базовую формы ссылку на содержащий её реестр
2) иметь один единственный реестр в приложении - глобальную переменную

client6aacНе годится... Action := caFree; делаем в базовой форме, которая ничего не знает про Form2

так From2 тут явно один из потомков базовой формы, то же самое, что frmMdiChildren1

zinpub


Зачем? переменная Sender перестаёт существовать через мгновение, когда ты выходишь из процедуры!

Arioch


Вот так лучше.

krapotkinболее практичным выглядит вариант когда это список моих объектов, которые содержат всякие данные и В ТОМ ЧИСЛЕ ссылку на форму.

после чего этот список начинает расти, а либо поиск, либо удаление объектов в массиве - операции дорогие

свалить ВСЕ объекты в одну кучу - спорное решение.

Arioch2) иметь один единственный реестр в приложении - глобальную переменную

А ещё лучше не глобальную, а локальную для класса

DimaBrНу так создавайте изначально так, чтобы такой формы небыло



Дважды вызывать функцию MDIChildren[i] - долго и потенциально моежт привести к опискам (например - несколько циклом, или индексы более разнообразные и сложные)

client6aacНо за наставление на путь истинный - спасибо!

в общем, несколько вариантов тебе накидали, плюсы-минусы упомянули, планировтаь будущее программы и оценивать их - дело уже твоё.

главное, не забывай, что "90% кода в интернете - говно" - https://www.gunsmoker.ru/2010/05/90.html

Якобы, задача такая, что не надо.
Скрестим пальцы, чтобы он не ошибся.


Есть тезис "не изобретать велосипеды"

goldmi45Зачем создавать то, что уже есть?

MDIChildren и MDIChildCo

И есть тезис "писать программу так, как будто через год её будет дописывать маньяк-убийца, которому расскажут, где живёт твоя семья"

zinpubНо Arioch прав, гораздо лучше реестр окон, в который можно добавить собственные свойства\методы

При этом тезис
client6aacВ текущей логике приложения как раз и нужно открытие окошек в единственном экземпляре.

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

провокация:
Хороший код такой, который легко ломается (т.е. от любого чиха перестаёт компилироваться).
Код, который компилируется даже после заметных изменений - плохой.

Пример - да хотя бы вечный срач про контроль типов (строгий / не строгий / никакого и статический / динамический), например https://www.sql.ru/forum/1309685/incompatible-types.

Собираем мой бред в кучку.

goldmi45Зачем создавать то, что уже есть?

MDIChildren и MDIChildCo

"Бизюзловно" - прозюзюкала Зази.

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

Но! если "другая логика" всё же случится, то "в класс-реестр можно добавить собственные свойства\методы".
А это значит, что в само объявление этих методов (списки/типы параметров, названия) можно зашить "требования к реальному миру". И при нарушении этих требований - компиляция сломается. И это - хороший код

DimaBr

Тут мы предполагаем, что "TMdiBaseFormClass" - полный и уникальный идентификатор формы.
ЕСЛИ потом у нас будут несколько форм одного класса, то будет что-то вроде




После этого всё позабытые нами вызовы "CreateFrom( MySuperMDIClass )" просто не соберутся. Даже если мы захотим их пропустить - Delphi не даст.

Но это - объявление метода.
А вот сам цикл - все равно будет собираться.

DimaBr


Если это цикл по любой причине начал копи-паститься в разных местах - мы обязательно где-нибудь его да забудем. Потому что "то, что уже есть" - никак на наши реалии не завязано. И поэтому не овалится (к сожалению), если мы реалии поменяем.

Таким образом, использование этого "из коробки" функционала - это очень сильная ставка на YAGNI.

Ну и "охотничья байка".
Есть стандартный срач в БД - суррогатный или натуральный должен быть ключ таблиц.
Должен ли уникальный идентификатор строки в таблице иметь реальный смысл или быть полностью очищен от любых пересечений с реальностью.

Несколько лет назад мне надо было быстро сделать самописку для внутренних нужд компании.
Среди прочего там была таблицы контрагентов - юр/лиц.
В качестве Primary Key я там поставил ИНН. Сразу многие запросы стали проще, а при просмотре вторичных таблиц вместу асбтрактного случайного номера - был реальный и осмысленный ИНН. Удобно и быстро.

....перед этим я всю контору обошёл и у всех спросил, могут ли в России быть два юр-лица с одинаковым ИНН. И мне все сказали, что конечно же нет, и вообще "программе это никогда не понадобится". Ну и я "срезал угол". Тем более, что надо было быстро.

Прошло полгода. У самописки появились пользователи, у пользователей появились привычки, в БД появились данные.

И вдруг ко мне приходят и говорят, что программа остановила работу. Надо ввести контр-агента ,а не получается, ругается на повтор ИНН.

- значит, вы его уже раньше ввели в БД, берите готовый.
- нет, тот "Василёк", а нужен "Ромашка".
- значит "Василёк" переименовался в ромашку. Переименуйте в БД и используйте.
- нет, это разные юр-лица и нам нужны ОБА СРАЗУ
- если это разные юр-лица, то у них и ИНН разные, ищите опечатку.
- нет опечаток. Юр-лица разные, а ИНН общий
- ЧТО ????

...оказалось, что хотя вообще-то ИНН - "индивидуальный номер", но конкретно у филиалов банокв в разных городах ИНН был общий, а различались только КПП.

Но ИНН уже был PK, на него уже были построены многие Foreign Key, но это были завязаны запросы и куски кода. И всё это уже было полгода в реальной работе.

....а мне надо бросив все срочно вспомнить как та программа писалась, сделать ИНН неуникальным - в программе и БД, и при этом не потерять данные, ни в чём не изменить поведение программы, и чтобы никто из пользователей вообще не заметил обновления.

...но вообще конечно же, YAGNI и "В текущей логике приложения как раз и нужно"
Делайте ваши ставки, господа!

Док,

- Долго ли умеючи?
- Умеючи-то долго!