Модальные формы и работа с ними

@dia3do · Регистрация: 19.02.2018

Студворк — интернет-сервис помощи студентам

В этом сообщении не буду рассматривать как создать форму авторизации используя модальное окно. Данный способ прекрасно описан здесь.
Собственно долго мучился с тем как правильно открывать и закрыть модальную форму №3 много раз, находясь в главном окне программы (форме № 2). Вроде все заработало, но история все равно остается какой-то мутной. Вот как я сделал:

C++
1
2
3
4
5
6
7
8
void __fastcall TForm2::Button1Click(TObject *Sender)
{
    TForm3 *frm3 = new TForm3(0);
    frm3->Left=Screen->Width/2-frm3->ClientWidth/2;  //выравниваем форму по центру
    frm3->Top=Screen->Height/2-frm3->ClientHeight/2; //выравниваем форму по центру
    frm3->ShowModal();
    
}

Во вновь созданной форме есть, кнопка "Закрыть" (Button), по нажатию которой форма закрывается

C++
1
2
3
4
void __fastcall TForm3::Button1Click(TObject *Sender)
{
 ModalResult = mrClose; //форма № 3 закрывается
}

Но почему-то в пособиях рекомендуют использовать следующую конструкцию для вызова и закрытия модальных форм:

C++
1
2
3
4
5
6
7
8
9
TFormX * FormX = new TFormX(0);
try
{
    FormX->ShowModal();
}
__finally
{
    delete FormX;
}

Вот только если такую конструкцию использовать, то форму № 3 хрен ты без ошибки закроешь. Ведь из Unit.cpp удалено TForm3 *Form3, из Unit.h удалено extern PACKAGE TForm3 *Form3, вроде как из-за того, что форма создается не автоматически, это позволяет избежать утечки памяти. Но в таком случае при работе с самой формой № 3 не получится ее закрыть обычным способом:

C++
1
Form3->Close();

или

C++
1
delete Form3;

Так вот вопрос: правильно ли я закрываю форму используя ModalResult = mrClose или нужно как-то победить delete FormX и заставить программу работать с ней?

Добавлено через 11 минут
Немного поясню, если использовать try/finally в главной форме, у меня это Form2, то как тогда по нажатию кнопки на третьей форме (Form3) закрыть эту самую Form3?

C++
1
2
3
4
5
6
7
8
9
TForm3 * Form3 = new TForm3(0);
try
{
    Form3->ShowModal();
}
__finally
{
    delete Form3;
}

Как тогда закрыть Form3?

C++
1
2
3
4
void __fastcall TForm3::Button1Click(TObject *Sender)
{
 ?????
}

@Avazart · 25.02.2018, 16:36

Сообщение от Fulcrum_013

Как раз это и говорит

Пока только Вы об этом говорите.

CreateForm() служит же как раз для кодогенерации и автосоздания форм.

Добавлено через 5 секунд

Сообщение от Fulcrum_013

Как раз это и говорит

Пока только Вы об этом говорите.

CreateForm() служит же как раз для кодогенерации и автосоздания форм.

@Fulcrum_013 · 25.02.2018, 16:52

Сообщение от Avazart

Пока только Вы об этом говорите.

Не говорить а действовать в этом направлении могут начать в любой заранее непредсказуемый момент. И вот тогда внезапно придется перепиливать кучу кода.

Сообщение от Avazart

CreateForm() служит же как раз для кодогенерации и автосоздания форм.

С таким же успехом можно автоматически сгенерировать

C++
1
TFormN = new TFormN(Appication);

но этого не делают именно потому что оставили точку расширения при создании формы.

@Avazart · 25.02.2018, 16:58

Сообщение от Fulcrum_013

С таким же успехом можно автоматически сгенерировать

Нет, в полной мере нельзя. Хотя бы тому что по коду видно что CreateForm() назначает первую форму главной.
Кроме того, скорее всего это дань Delphi где нет того самого new и делаетcя все через метод Create.

@Fulcrum_013 · 25.02.2018, 17:07

Сообщение от Avazart

Нет, в полной мере нельзя. Хотя бы тому что по коду видно что CreateForm() назначает первую форму главной.

Вот в том то и дело что поведение уже в текущей реализации не на 100% соответствует просто вызову new. Хотя назначение формы главной в принципе можно разгребать в методе привязки компонента-формы к хозяину-приложению но через даункаст. Именно чтобы не разгребать кто есть кто для форм сделали специальный метод создания. Возможность внесения дальнейших изменений в поведение может вообще сделать неработоспособной формы созданные через new. Не факт что это будут менять. Но при этом нет и никакой гарантии что не поменяют. Так что лучше пользоваться специально предназначенным для этого средством чем надеяться на то что поведение никогда не изменится.

@Avazart · 25.02.2018, 17:12

Сообщение от Fulcrum_013

Вот в том то и дело что поведение уже в текущей реализации не на 100% соответствует просто вызову new

А это не важно. Конкретно в данном случае, а так же для большинства других случаев.

@Reavolt · 25.02.2018, 17:12

Не по теме:

Интересный спор у вас тут, если не затруднит ткните меня носом в корень проблемы пожалуйста, там как раз вопрос немного связан с формами. -> Тык

@Fulcrum_013 · 25.02.2018, 17:21

Сообщение от Avazart

А это не важно. Конкретно в данном случае, а так же для большинства других случаев.

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

@Avazart · 25.02.2018, 17:31

Сообщение от Fulcrum_013

Важно то что это может стать некорректным в следующих версиях VCL.

Не может.
Ибо форма внутри этой ф-ции создается через тот же конструктор, и логично что это никогда не поменяется.

@Fulcrum_013 · 25.02.2018, 17:35

Сообщение от Avazart

бо форма внутри этой ф-ции создается через тот же конструктор, и логично что это никогда не поменяется.

Но может поменяться/добавится куча всего того что делается кроме вызова конструктора. К примеру добавится внесение формы в какой либо подкапотный список и т.п.

@Avazart · 25.02.2018, 18:14

Сообщение от Fulcrum_013

К примеру добавится внесение формы в какой либо подкапотный список и т.п.

Надеюсь разработчики не такие идиоты.

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

@Fulcrum_013 · 25.02.2018, 20:11

Сообщение от Avazart

Надеюсь разработчики не такие идиоты.

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

Сообщение от Avazart

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

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

@Avazart · 25.02.2018, 20:14

Сообщение от Fulcrum_013

В данном случае идиотами окажутся те кто пишет код нарушающий контракт.

Какой еще контракт? Вы видели что упоминание об этом?

@Fulcrum_013 · 25.02.2018, 20:16

Avazart, Вот именно на создание форм через фабричный метод приложения.

@Avazart · 25.02.2018, 20:18

Сообщение от Fulcrum_013

Хотя бы по той причине что пока VCL делана на дельфе и пользует виртуальные конструкторы единственным способом гарантировать в компайл-тайме что хозяин будет заданного типа это использовать фабричный метод хозяина. Мало того любителям указывать nullptr в качестве хозяина не поможет даже такая упаковка дополнительных действий в конструктор.

Я же говорю Вы бездарь что в С++ что в Delphi.
В делфи можно так же использовать конструктор, просто выглядит иначе.
Конструктор открытый что в С++ что Delphi, а значит никто не запрещает использовать его.

То что есть какай-то дополнительный метод другого класса, делающий доп. действия не означает что кто-то запрещает использовать конструктор.

@Fulcrum_013 · 25.02.2018, 21:28

Сообщение от Avazart

Я же говорю Вы бездарь что в С++ что в Delphi.

Сам ты бездарь в плане алгоритмов и архитектуры. В паскале конструктор не может быть закрыт в следствие отсутствия механизма friend-доступа. То что конструктор формы открыт это реально дыра в архитектуре.
Avazart, Вообще в VCL еще дохрена дыр кроме открытых конструкторов форм. И все они в своем подавляющем большинстве растут из нарушения инкапсуляции взаимодействия между объектами в следствие отсутствия механизма friend-доступа. При этом в случае возникновения каких то изменений при использовании CreateForm в дыру точно не провалишься в отличии от пользования конструктора формы. Это еще во времена первой дельфи выясняли.

Добавлено через 1 час 0 минут

Сообщение от Avazart

Но в большинстве случаев всегда, для того что бы в памяти не висела.

Вот это действительно полный бред. От этой глупости во всю отучали еще когда оной памяти 640KB было и была еще далеко не VCL. Во первых потому что висение в памяти это меньшее из зол по сравнению с перевыделением памяти на каждое телодвижение. Ну а в главных потому что в подавляющем большинстве случаев введенные данные при повторном открытии должны быть на месте и во многих случаях с историей ввода. При этом костылить систему их сохранения где то еще и потом восстановления в большинстве случаев по памяти особо не выиграешь а по всем остальном проиграешь. При этом "тяжелые" элементы типа таблиц BD и т.п. можно включать/отключать при открытии/закрытии.

@Avazart · 25.02.2018, 21:45

Сообщение от Fulcrum_013

Сам ты бездарь в плане алгоритмов и архитектуры. В паскале конструктор не может быть закрыт в следствие отсутствия механизма friend-доступа.

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

Сообщение от Fulcrum_013

Avazart, Вообще в VCL еще дохрена дыр кроме открытых конструкторов форм. И все они в своем подавляющем большинстве растут из нарушения инкапсуляции взаимодействия между объектами в следствие отсутствия механизма friend-доступа. При этом в случае возникновения каких то изменений при использовании CreateForm в дыру точно не провалишься в отличии от пользования конструктора формы. Это еще во времена первой дельфи выясняли.

Единственные дыры это published секции, в остальном дыр не так уж много.
А тут инкапсуляция не нужна ибо форма вполне самостоятельная сущность.

Добавлено через 5 минут

Сообщение от Fulcrum_013

Вот это действительно полный бред. От этой глупости во всю отучали еще когда оной памяти 640KB было и была еще далеко не VCL. Во первых потому что висение в памяти это меньшее из зол по сравнению с перевыделением памяти на каждое телодвижение. Ну а в главных потому что в подавляющем большинстве случаев введенные данные при повторном открытии должны быть на месте и во многих случаях с историей ввода. При этом костылить систему их сохранения где то еще и потом восстановления в большинстве случаев по памяти особо не выиграешь а по всем остальном проиграешь. При этом "тяжелые" элементы типа таблиц BD и т.п. можно включать/отключать при открытии/закрытии.

Не важно сколько у Вас памяти, она всегда конечна.

@Fulcrum_013 · 25.02.2018, 22:07

Сообщение от Avazart

Вполне может быть закрыт.

Сообщение от Avazart

"Friend-доступе" нет необходимости ибо пределах модуля видны все ф-ции.

Только фабрика которая его вызывает по архитектуре должна жить в другом модуле.
И там еще куча таких моментов. В другие дыры просто влезть гораздо сложнее. Например в дыру с открытым доступом к Controls у TRadioGroup который может обрушить программу. Кстати именно по этой причине все в свое время так ожидали билдер - думали в плюсовой версии VCL этих архитектурных дыр не будет.

Добавлено через 3 минуты

Сообщение от Avazart

Не важно сколько у Вас памяти, она всегда конечна.

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

@Avazart · 25.02.2018, 22:18

Сообщение от Fulcrum_013

Только фабрика которая его вызывает по архитектуре должна жить в другом модуле.

В каком другом? Все находится в одном модуле.
По факту а не то что вы себе на воображали.

@Fulcrum_013 · 25.02.2018, 22:37

Avazart, Конструктор порожденной формы а не самой TForm. При этом конструктится она вообще через метакласс, а закрытый конструктор в RTTI таблицу по дефаултным настройкам попасть не может.

@Avazart · 25.02.2018, 22:48

Сообщение от Fulcrum_013

Конструктор порожденной формы а не самой TForm.

А нормальным языком?

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@Reavolt
	25.02.2018, 17:12
	Не по теме: Интересный спор у вас тут, если не затруднит ткните меня носом в корень проблемы пожалуйста, там как раз вопрос немного связан с формами. -> Тык 0

@Fulcrum_013 2083 / 1574 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	25.02.2018, 20:16
	Avazart, Вот именно на создание форм через фабричный метод приложения. 0

@Fulcrum_013 2083 / 1574 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	25.02.2018, 22:37
	Avazart, Конструктор порожденной формы а не самой TForm. При этом конструктится она вообще через метакласс, а закрытый конструктор в RTTI таблицу по дефаултным настройкам попасть не может. 0