Про работу с фреймами

← →
Alek © (2004-08-12 14:02) [0]

Как работать с фреймами во время выполнения программы?
Создавать и удалять?

← →
GuAV © (2004-08-12 14:06) [1]

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

← →
Alek © (2004-08-12 14:18) [2]

Вот Так я создаю фрейм:

If not Assigned(Sootvetstviya1) then Sootvetstviya1:=TSootvetstviya.Create(Application);
Sootvetstviya1.Parent:=Panel2;
Sootvetstviya1.Left:=8;
Sootvetstviya1.Top:=8;

Вешаю ему обработчик нажатия на кнопку
Sootvetstviya1.SpeedButton1.OnClick:=Sootvetstviya1SpeedButton1Click;

Вот сам обработчик:
procedure TForm1.Sootvetstviya1SpeedButton1Click(Sender: TObject);
begin
FreeAndNil(Sootvetstviya1);
end;

Когда он срабатывает ты вылетает исключение, но фрейм удаляется.
Что я неправильно делаю?

← →
jack128 © (2004-08-12 14:20) [3]

> procedure TForm1.Sootvetstviya1SpeedButton1Click(Sender:
> TObject);
> begin
> FreeAndNil(Sootvetstviya1);
> end;
так делать нельзя. Посмотри как реализован TCustomForm.Release и сделай так же.

← →
GuAV © (2004-08-12 14:22) [4]

> Что я неправильно делаю?

RTFM:
Release method (TCustomForm)

Sootvetstviya1.Release
Sootvetstviya1:=nil

← →
GuAV © (2004-08-12 14:24) [5]

> TCustomForm.Release

TCustomForm(Self).Release; - думаю пойдёт...

← →
QQ © (2004-08-12 14:28) [6]

У меня ничего не вылетает. Какое исключение?

← →
Alek © (2004-08-12 14:31) [7]

PostMessage(AddZapchast1.Handle, CM_RELEASE, 0, 0);
AddZapchast1:=nil;

неработает. Первое нажатие кнопки ничего не исчезает, а на второе вылетает ексцептион

← →
Alek © (2004-08-12 14:32) [8]

FreeAndNil(Sootvetstviya1); - вот если я вешаю это на кнопку которая не принадлежит Sootvetstviya1, то все нормлаьно освободжлдается, а если кнопка пренадлежит Sootvetstviya1 то вылетает исключение и фрейм освобождается

← →
GuAV © (2004-08-12 14:36) [9]

Мне когда-то нужно было чтоб кнопка убивала себя... выкрутился через postmessage wm_user+x главой форме.

← →
QQ © (2004-08-12 14:38) [10]

И вообще это неправильный путь. Коли уж создаём фрейм рантайм, то указывайте как овнера форму, где она лежит. Owner это как раз и есть класс, ответственный за освобождение памяти вашего фрейма (или чего-то там еще). Т. е. нужно писать:
If not Assigned(Sootvetstviya1) then Sootvetstviya1:=TSootvetstviya.Create(Form1);
где вместо Form1 - имя формы, где этот фрейм лежит. Тогда и освобождать ничего в ручную не придётся.

← →
GuAV © (2004-08-12 14:42) [11]

GuAV © (12.08.04 14:36) [9]
Это в смысле PostMessage надо делать той форме, где обработчик, т.е. в к-рую вставлен Frame. А Sootvetstviya1 - передавать например в lParam

← →
QQ © (2004-08-12 14:42) [12]

а ты проверь-ка после FreeAndNil(Sootvetstviya1);
у тебя есть какой-нить код в этом обработчике нажатия на кнопку?
;)

← →
QQ © (2004-08-12 14:46) [13]

И вообще, как Вы так пишите??
должно быть: FreeAndNil(Self);
если речь об освобождении собственной памяти у фрейма.

← →
QQ © (2004-08-12 14:55) [14]

а вообще - GuAV прав - требуется написать обработчик сообщения в форме, который будет делать FreeAndNil(Sootvetstviya1);

← →
GuAV © (2004-08-12 15:05) [15]

Я бы лучше в обработчике делал TObject(Message.lParam).Free; а :=nil после того постмесаге:

procedure TForm1.FreeandNilFrame(var Frame: TFrame);
begin
PostMessage(Self.Handle,WM_MYFREE,0,LPARAM(Frame));
Frame:=nil;
end;

← →
jack128 © (2004-08-12 17:14) [16]

> procedure TForm1.FreeandNilFrame(var Frame: TFrame);
> begin
> PostMessage(Self.Handle,WM_MYFREE,0,LPARAM(Frame));
> Frame:=nil;
> end;

технически правильный подход, но лудше реализовать эту функциональность в самом фрейме.
Я в свое время задовался вопросом - почему метод Release ввели только для CustomForm, а не для WinControl"ов..

← →
GuAV © (2004-08-12 18:36) [17]

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

TForm(Frame).Release; ?

> Я в свое время задовался вопросом - почему метод Release
> ввели только для CustomForm, а не для WinControl"ов..

И почему же ?
<off>
Чем кстати про конструктор как обычный метод закончилось ?
</off>

← →
QQ © (2004-08-12 18:46) [18]

> GuAV [17]
> TForm(Frame).Release; ?
не работает

← →
GuAV © (2004-08-12 19:06) [19]

QQ © (12.08.04 18:46) [18]
Так к чему я это:
jack128 © (12.08.04 17:14) [16]

> реализовать эту функциональность в самом фрейме.

В данном случае не получается.

← →
jack128 © (2004-08-12 19:09) [20]

> > GuAV [17]
> > TForm(Frame).Release; ?
> не работает

> В данном случае не получается

Я имел ввиду вот так:
TMyCoolFrame = class(TFrame)
private
procedure CmRelease(var Message: TMessage); message CM_RELEASE;
end;

procedure TMyCoolFrame.CmRelease(var Message: TMessage);
begin
Free;
end;

procedure TMyCoolFrame.Release;
begin
PostMessage(Handle, CM_RELEASE, 0, 0);
end;
> <off>
> Чем кстати про конструктор как обычный метод закончилось
> </off>
А ничем. Вопрос не вызвал интузиазма среди общественности.. Ну фиг с ним. По большому счету мне все равно - вопрос был риторическим.. Хотя ты, помнится хотел в борланд по этому счету написать ;-)

← →
GuAV © (2004-08-12 21:07) [21]

> Хотя ты, помнится хотел в борланд по этому счету написать
> ;-)

Я думал, что выяснили. Ладно, в MS писал, и этим напишу.

← →
GuAV © (2004-08-12 22:11) [22]

> Я имел ввиду вот так:
> TMyCoolFrame = class(TFrame)
> private
> procedure CmRelease(var Message: TMessage); message CM_RELEASE;
> end;
>
> procedure TMyCoolFrame.CmRelease(var Message: TMessage);
> begin
> Free;
> end;

и чем это отличается от TForm(Frame).Release ?
дело как мне предсавляется в том, что обработчик кнопки в форме а не в фрейме и соотв. postmessage надо туда же [15].

← →
jack128 © (2004-08-12 22:24) [23]

> и чем это отличается от TForm(Frame).Release ?
тем что у TFrame нету метода Release, а TMyCoolFrame есть ;-)

← →
GuAV © (2004-08-12 22:30) [24]

> TFrame нету метода Release

Блин, я почему то думал, что TCustomFrame наследник TCustomForm...

← →
jack128 © (2004-08-12 22:31) [25]

попробуй сам - если ты в фрейме обработаешь CM_RELEASE, то твой код
> TForm(Frame).Release
заработает ;-)

← →
GuAV © (2004-08-13 01:45) [26]

> заработает ;-)

Охотно верю, он для любого TWinControla заработает, полей то нет :)

А как убить объект из самого себя, не имея окна?

Уничтожение объектом самого себя - глупость изначально.
Уничтожать должен тот, кто создал. Только так.
То, что это сделано для форм причем внутри их же - ну просто так вот.
Хотя, метод Release в принципе сделать не трудно для любого компонента, только в нем фактически "просить" уничтожить себя другой объект. Какой - и как не важно, много можно насочинять. При этом реальное уничтожение должно происходить вне какого-либо метода уничтожаемого объекта. Что понятно.

KSergey © (13.08.04 11:26) [28]

> Уничтожение объектом самого себя - глупость изначально.

Free + (Ctrl+Мыша)

> только в нем фактически "просить" уничтожить себя другой
> объект.

Нифига подобного - в CM_RELEASE Написано Free.

> Что понятно

Что бред.
GrayFace © (13.08.04 11:20) [27]

> А как убить объект из самого себя, не имея окна?

При чём тут окно? Его имеют далеко не все объекты, и даже не все компоненты. Убить из себя - Free.

---
Учите исходники Дельфи, ребята...

> [29] GuAV © (13.08.04 14:51)
> > Уничтожение объектом самого себя - глупость изначально.
> Free + (Ctrl+Мыша)

Блин, ну не совсем корректно написал
Имелось в виду, конечно же - убиение себя (вызов Free) из своего же метода.
Да, да, я понимаю, что есть CM_RELEASE, более того, оно работает.

Но предлагаю считать его все же - исключением! Причем - недостойным подражания.

> Но предлагаю считать его все же - исключением! Причем -
> недостойным подражания.

Отвергаю это предложение. Автор ветки хотел таки уничтожить объект из себя и он прав.
Объект нельзя уничтожать из себя, когда после уничтожения использованы свойства и методы требующие наличие объекта, а также поля объекта. Например:
1) Когда после уничтожения будут выполнятся события. В событиях ничего не подозревающий кодер может использовать свойства и методы требующие наличие объекта.
2) -//- сообщения. В обработчиках этих сообщений могут использаться свойства и методы требующие наличие объекта, а также поля объекта.
3) Когда присутсвует "непосредственное" обращение к полю/методу/св-ву объекта после его уничтожения, т. е. в одной из процедур, находящейся в "call stack". 1 - частный случай этого.
4) Внутри событий. Если не оговорено, то не гарантируется отсутствие вышеозначенных пунктов.

Однако, если после уничтожения не использованы использованы свойства и методы требующие наличие объекта, а также поля объекта, то уничтожать объект можно.

Автору ветки: не слушай KSergey и GrayFace, слушай jack128 и меня :)

> GuAV © (13.08.04 16:25) [31]

Следуя этому совету имеем:

1.Необходимость каждый раз крепко копать код VCL. Ну, в принципе полезно, конечно.
2.В случае чего- огребаем плавающие баги.

Вам мало проблем без этого? ;)
Хотя, конечно, кому как проще.

> 1.Необходимость каждый раз крепко копать код VCL. Ну, в
> принципе полезно, конечно.
> 2.В случае чего- огребаем плавающие баги.

Нифига подобного. PostMessage+Free - и никаких проблем. А в VCL заглянули, чтобы эту идею спионерить из release. И только. А вообще это полезно, конечно.

> [33] GuAV © (13.08.04 22:01)
> PostMessage

Хорошо, когда его есть кому запруздырить ;)
Но все равно в кахдом сулчае подход будет индивидуален...

Короче я не спорю, что делать так можно. Речь веду о том - нужно ли?

> Речь веду о том - нужно ли?

Это самый простой путь решения данной проблемы.
В конце-то концов, ну "попросишь кого-то" прибить объект. Он убъёт и передаст управление вызывавшей процедуре. Т.е. всё равно объект убъёт себя из себя. Без постмессаге тут всё равно не обойтись.

> Но все равно в кахдом сулчае подход будет индивидуален...

Называй другие случаи - разберёмся.

> [35] GuAV © (14.08.04 13:52)
> Это самый простой путь решения данной проблемы.
> В конце-то концов, ну "попросишь кого-то" прибить объект.
> Он убъёт и передаст управление вызывавшей процедуре. Т.е.
> всё равно объект убъёт себя из себя. Без постмессаге тут
> всё равно не обойтись.

Разумеется не обойтись!
Под "попросить" я имел в виду "вежливо", т.е. не буквально сразу ;) Именно что вне какого либо метода уничтожаемого объекта вызвать деструктор.

> Называй другие случаи - разберёмся.

Лень фантазировать. ;)
Разобраться, думаю, можно почти всегда (в смысле найти решение буквально желаемой штуки), однако, по-моему, в этом нет особого смысла.
Впрочем, я просто предостерегаю в том смысле, что в лоб может не получится. Но если хочется - да сколько угодно! ;)

GrayFace © (13.08.04 11:20) [27]
> Уничтожение объектом самого себя - глупость
>изначально.
> Уничтожать должен тот, кто создал. Только так.

Создает статический метод класса, а сам объект слушает у каогт-то контрола сообщения и на wm_destroy должен убиваться.

Про работу с фреймами Найти похожие ветки