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

@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.

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

Новые блоги и статьи Все статьи Все блоги /
Doom для терминала без стрельбы и монстров. 3D Raycasting на ascii. dcc0 05.07.2026 Попросил нейронную сеть deepai. org написать рейкастинг 3D с библиотекой ncurses для Linux. Чтобы можно было ходить на стрелочки. Чтобы стены были отрисованы символами. Справилась. Первый вариант. . .	Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .	В чем ценность человеческого опыта в глобальном смысле? kumehtar 03.07.2026 Возможно, ценность человека не в том, что он однажды достигает мудрости, а в том, что он становится носителем карты пути. Он знает не только истину, но и последовательность внутренних изменений,. . .
интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .	Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .

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

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

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