Parent

← →
malkolinge (2003-02-24 11:42) [0]

У меня вот созрел вопрос.. Если в ран тайме создать панель а на ней кнопку (панель родитель для кнопки) а потом грохнуть панель, кнопка грохенться или нет. Овнер для кнопки - форма ?

← →
Palladin (2003-02-24 11:51) [1]

Созрел вопрос...
пусть зреет эксперимент..

← →
Anatoly Podgoretsky (2003-02-24 12:06) [2]

Если все правильно написано, то удалется, если не правильно, то грохается.

← →
Юрий Зотов (2003-02-24 12:53) [3]

Owner для созданной в run-time кнопки - это тот компонент, который Вы указали при вызове ее конструктора.

← →
malkolinge (2003-02-24 14:48) [4]

> Owner для созданной в run-time кнопки - это тот компонент,
> который Вы указали при вызове ее конструктора.

А я - то думал почему это в конструкторе параметр требуют...Овнер ^). Нет Юрий спасибо я это итак знаю, но вопрос в следующем

код
pn1:=Tpanel.Create(self);
pn1.parent:=Self;

But:=TButton.Create(Self) // Владелец форма
but.Parent:=pn1 // панель отображает кнопку (владеет)

что будет с кнопкой при вызове
pn1.Free ????

← →
Юрий Зотов (2003-02-24 15:58) [5]

Скомпилируйте проект с опцией "Use debug DCU"s", поставьте BreakPoint в TWinControl.Destroy и в Watch List поставьте Name.

При уничтожении панели приходим сюда дважды:
1. Уничтожается Panel1.
2. Уничтожается Button1.

Думаю, это снимает все вопросы. Если интересуют детали, то они в том же деструкторе:

I := ControlCount;
while I <> 0 do
begin
Instance := Controls[I - 1];
Remove(Instance);
Instance.Destroy;
I := ControlCount;
end;

← →
Юрий Зотов (2003-02-24 16:13) [6]

Пояснение: кнопка уничтожается, как КОНТРОЛ, но не как объект. То есть, она теряет хэндл окна, теряет Parent"а и даже Owner"а - но если поставить тормоз в TObject.Free или TObject.FreeInstance, то увидим, что ЭТИ методы для кнопки НЕ вызываются.

← →
oomneeq (2003-02-24 17:07) [7]

>Юрий Зотов © (24.02.03 16:13)
>кнопка уничтожается, как КОНТРОЛ, но не как объект
Юрий, но ведь Destroy то вызывается тот что надо, он же виртуальный. И цель достигается та же - объект уничтожен.
Уничтожен правильно, собственным деструктором.

В чем тогда принципиальное различие между уничтожением как контрола и как объекта.
Насколько это важно и важно ли?

и как на ваш взгляд, не выглядит ли такое поведение некорректным?
Я имею ввиду разрушение компоненты НЕ владельцем, а родителем?
зачем он его разрушает, он же не владелец?

В чем сермяжная правда?

← →
Mike_Goblin (2003-02-24 17:39) [8]

>Я имею ввиду разрушение компоненты НЕ владельцем, а родителем?
>зачем он его разрушает, он же не владелец?
Потому что при "смерти" родителя(parent) уничтожается дескриптор его окна, который нужен его контролам для рисования себя

← →
oomneeq (2003-02-24 20:16) [9]

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

поправьте меня, если я заблуждаюсь.

← →
Романов Р.В. (2003-02-24 20:23) [10]

oomneeq © (24.02.03 20:16)

destructor TWinControl.Destroy;
var
I: Integer;
Instance: TControl;
begin
Destroying;
if FDockSite then
begin
FDockSite := False;
RegisterDockSite(Self, False);
end;
FDockManager := nil;
FDockClients.Free;
if Parent <> nil then RemoveFocus(True);
if FHandle <> 0 then DestroyWindowHandle;
I := ControlCount;
while I <> 0 do
begin
Instance := Controls[I - 1];
Remove(Instance);
Instance.Destroy;
I := ControlCount;
end;
FBrush.Free;
if FObjectInstance <> nil then FreeObjectInstance(FObjectInstance);
inherited Destroy;
end;

← →
oomneeq (2003-02-24 20:34) [11]

>Романов Р.В. © (24.02.03 20:23)

Я вижу, что это так, но само по себе оно не объясняет, почему это так.

что поломается, если выбросить стороку
Instance.Destroy;
?

← →
Романов Р.В. (2003-02-24 21:00) [12]

Скорее всего получишь AV или утечку ресурсов.

> Вспомните расхожий вопрос о том почему не видно динамически
> созданой кнопки. потому что не назначен родитель. но кнопка
> то жива! Назначаешь родителя (.Parent:=Form1) и ее становится
> видно.

Кнопка то жива но только как Дельфовская обертка кнопки Windows, т.е. окно которое визуально изображает кнопку еще не создано. Оно создается перед тем когда должно быть первый раз показано.

А что ей бедной нужно будет делать поcле удаления своего родителя. На чем рисоваться, с кем взаимодействовать?

← →
oomneeq (2003-02-24 21:12) [13]

>Скорее всего получишь AV или утечку ресурсов.
ну хотя бы намекни, с какой радости?

>А что ей бедной нужно будет делать поcле удаления своего родителя. На чем рисоваться, с кем взаимодействовать?
Тоже самое, что и вновь созданной - подождать, пока добрый человек присвоит родителя. или владелец не грохнет.

Криминала то нету.
Ведь есть правило - о созданных компонентах заботится владелец.
или программист. А тут - родитель. Нелогично. IMHO.
Хочется мне поттверждения. Или опровержения.
Аргументированного.

← →
Романов Р.В. (2003-02-24 22:50) [14]

Читаем справку API
DestroyWindow
If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.

Т.е. сама windows уничтожает все child окна. А в выделеном фрагменте уничтожается их VCL оберка. Зачем хранить фантики от конфет которые съедены нужно их сразу выбрасыть, что бы мусор не копить. Конечно в эту оберку можно завернуть другое окно, но проще сделать новый компонент с новым окном.

← →
oomneeq (2003-02-25 01:49) [15]

со справкой API все понятно
речь ведь не об идеологии WinAPI а VCL-вском коде.

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

>но проще сделать новый компонент
чем проще?
новый надо делать, старый уже есть.

В учебниках да и в ответах начинающим особо подчеркивают разницу между родителем и владельцем а тут в самых недрах VCL
родитель берет на себя чужие функции.
Наша дискуссия носит скорее теоретический, и может даже отвлеченный характер. Просто на мой взгляд мы имеем пример отклонения от cтройных правил, считающимися достоинством VCL.
На такое отклонение должна imho быть более серьезная причина чем житейская мудрость. Но она то и не очевидна.
Ув. Романов Р.В., при всем к тебе уважении я твоих постингах ее не узрел. Может быть еще кто внесет свежую струю?
Смелее, господа теоретики! :)
Хотелось бы послушать и начальника транспортного цеха :)

← →
Nemo (2003-02-25 03:45) [16]

Вот что я думаю по этому поводу.
Я провел небольшое расследование и вот что я выяснил.
Что я делал.
Первое приложение создавало кнопку и с помощью Windows.SetParent "переправляло" ее во второе приложение. После чего, второе приложение закрывалось, а с помощью заранее сохраненного хэндла созданной кнопки была предпринята попытка вернуть кнопку в "родное" приложение. Попытка провалилась.
Отсюда, думаю, можно сделать вывод, что приложение, на которое настроено свойство Parent также как и родительское УНИЧТОЖАЕТ кнопку.
Всем спасибо.

← →
oomneeq (2003-02-25 09:32) [17]

Nemo, да не отом речь...
а то, что уничтожает (только не приложение, а контрол - родитель) - это как раз и есть предмет обсуждения.

>Всем спасибо.
и тебе спасибо за участие :)

← →
Романов Р.В. (2003-02-25 18:23) [18]

> oomneeq © (25.02.03 01:49)
> В учебниках да и в ответах начинающим особо подчеркивают
> разницу между родителем и владельцем а тут в самых недрах
> VCL родитель берет на себя чужие функции.
> Просто на мой взгляд мы имеем пример отклонения от cтройных
> правил, считающимися достоинством VCL.

Почему вы решили что это чужие функции. Действительно свойство Owner предназначено для реализации механизма освобождения памяти, с целью облегчения работы программиста. Но никто не запрещает освобождать компоненты до удаления их владельца. Если этим может заниматься программист, то почему это не может сделать другой компонент?
Давайте рассуждать следуя вашему пониманию VCL.
Если в Run-Time при удалении Parent не удалит своих детей, то очевидно он будет должен прописать всем им Parent := nil и тогда они станут невидимыми, ожидая присвоения нового Parent. При завершении приложения Owner, то есть форма удалит все компоненты. Все вроде бы логично.
Теперь рассмотрим Design-Time. Не секрет что Delphi использует один и тот же конструктор/деструктор компонента как в Run-Time так и в Design-Time. Допустим мы поместили на форму панель и 3 кнопки. При удалении панели Parent у кнопок делаем nil и они исчезают с экрана. Вопрос как теперь назначить невидимым кнопкам Parent? Нужно свойство Parent добавить в Object Inspector и сделать редактор этого свойства. Теперь если кнопки могут существовать без Parent то они могут быть сохранены в DFM файл и так и болтаться потом в программе занимая память. Даже если это не утечка ресурса, то нерациональный расход памяти.
Вот такая "стройная" модель у нас получается.

Parent Найти похожие ветки