Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2008-04

TCustomApplication's parent class?

10 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

Why does TCustomApplication derive from TComponent instead of TObject? What is the reason behind this? Is there any benefits unknown to me? Surely we never need to persist the Appplication class. And it it's because we wanted RTTI support, again we could have enabled that for a TObject descendant with {$M+} compiler directives.

TCustomApplication = Class(TComponent)
....
end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Vincent Snijders
to Graeme Geldenhuys
Graeme Geldenhuys wrote 12 lines
Hi, Why does TCustomApplication derive from TComponent instead of TObject? What is the reason behind this? Is there any benefits unknown to me? Surely we never need to persist the Appplication class. And it it's because we wanted RTTI support, again we could have enabled that for a TObject descendant with {$M+} compiler directives. TCustomApplication = Class(TComponent) .... end;

It most probably is not unknown to you: the most important benefit of being TComponent is that you can be owner of other components, so that eases memory management. The Application can become responsible for freeing the components it owns.

Vincent

Reply by email

Mattias Gaertner
to Vincent Snijders
Show quoted text 19 lines
Graeme Geldenhuys schreef: > Hi, > > Why does TCustomApplication derive from TComponent instead of > TObject? What is the reason behind this? Is there any benefits > unknown to me? Surely we never need to persist the Appplication > class. And it it's because we wanted RTTI support, again we could > have enabled that for a TObject descendant with {$M+} compiler > directives. > > > TCustomApplication = Class(TComponent) > .... > end; It most probably is not unknown to you: the most important benefit of being TComponent is that you can be owner of other components, so that eases memory management. The Application can become responsible for freeing the components it owns.

And don't forget the second feature. Via FreeNotification Application is notified, when a component is freed.

Mattias

Reply by email

Graeme Geldenhuys
to Vincent Snijders: It most probably is not unknown to you: the most important benefit of being TComponent is…

2008/4/26 Vincent Snijders :

It most probably is not unknown to you: the most important benefit of being TComponent is that you can be owner of other components, so that eases memory management. The Application can become responsible for freeing the components it owns.

OK, the owner idea is handy, but what other than Forms or DataModules would Application want to own?

I've just changed fpGUI so that it's Application class descends from TObject, and maintains an internal list (TList) of objects created via Application.CreateForm(). I've had constant memory leaks I couldn't track down, but changing Application to a TObject and maintaining the internal list myself fixed all the memory leak issues.

Maybe my understanding of TComponent's ability to free owned objects are lacking. Is there something special I was supposed to do, so that TComponent can free off any owned objects?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Mattias Gaertner: On Sat, 26 Apr 2008 10:52:49 +0200 And don't forget the second feature. Via…

2008/4/26 Mattias Gaertner :

And don't forget the second feature. Via FreeNotification Application is notified, when a component is freed.

I'll have to read more about this subject to fully understand it. I accomplish the same thing (I think) with fpGUI forms at the moment. When the forms are told to be destroyed (CloseAction = caFree), they post a message to the Application object, which removes them from the internal TList in Application and free and nullifies them. For obvious reasons, the Form can't free and nullify itself (if you try, you get lovely runtime errors). :)

I did all this to fully support 'modeless' forms in fpGUI and creating instances of forms via Application.CreateForm().

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gaertner
to Graeme Geldenhuys: 2008/4/26 Vincent Snijders : OK, the owner idea is handy, but what other than Forms or…
Show quoted text 9 lines
2008/4/26 Vincent Snijders : > It most probably is not unknown to you: the most important benefit > of being TComponent is that you can be owner of other components, > so that eases memory management. The Application can become > responsible for freeing the components it owns. OK, the owner idea is handy, but what other than Forms or DataModules would Application want to own?

TCustomApplication is not only for LCL. For example cgi applications.

Show quoted text 5 lines
I've just changed fpGUI so that it's Application class descends from TObject, and maintains an internal list (TList) of objects created via Application.CreateForm(). I've had constant memory leaks I couldn't track down, but changing Application to a TObject and maintaining the internal list myself fixed all the memory leak issues.

Maybe you freed in the wrong order.
The position of the 'inherited Destroy' call in TApplication.Destroy may be important.

Maybe my understanding of TComponent's ability to free owned objects are lacking. Is there something special I was supposed to do, so that TComponent can free off any owned objects?

Probably you did too much.
Don't double free components.
You can check with csDestroying in ComponentState.

Mattias

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Why does TCustomApplication derive from TComponent instead of TObject? What is the reason…
Graeme Geldenhuys wrote 7 lines
Hi, Why does TCustomApplication derive from TComponent instead of TObject? What is the reason behind this? Is there any benefits unknown to me? Surely we never need to persist the Appplication class. And it it's because we wanted RTTI support, again we could have enabled that for a TObject descendant with {$M+} compiler directives.

TCustomApplication is the owner of TForm/TDataModule classes by default.

Other than that, you can create any component, and make sure it's freed correctly when the application terminates, by creating it with the global Application instance as the parent class. I often do this in custom code.

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt

2008/4/26 Michael Van Canneyt :

Show quoted text 6 lines
TCustomApplication is the owner of TForm/TDataModule classes by default. Other than that, you can create any component, and make sure it's freed correctly when the application terminates, by creating it with the global Application instance as the parent class. I often do this in custom code.

I just noticed that it is common usage to call
SomeForm.Create(Application), which is now not possible. As it stands now, it breaks your fpGUI article's demo application as well, which I don't want to do. :)

OK, I'll change TfpgApplicationBase to derive from TComponent again.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Sergei Gorelkin
to Graeme Geldenhuys
Graeme Geldenhuys wrote 5 lines
I just noticed that it is common usage to call SomeForm.Create(Application), which is now not possible. As it stands now, it breaks your fpGUI article's demo application as well, which I don't want to do. :)

In fact, TSomeForm.Create(Application) should work and should be enough for all cases. In my vision, the purpose of Application.CreateForm is a workaround for odd VCL architecture: it assigns object reference before calling its constructor, so that you can use global variables like "Form1" within FormCreate handler without getting a segfault. But doing so is bad, extremely bad practice...

OK, I'll change TfpgApplicationBase to derive from TComponent again.

Finding a solution of the problem is always better, although harder, than masking it out :)

Best regards,
Sergei

Reply by email

Graeme Geldenhuys
to Sergei Gorelkin

2008/4/27 Sergei Gorelkin :

Show quoted text 6 lines
In fact, TSomeForm.Create(Application) should work and should be enough for all cases. In my vision, the purpose of Application.CreateForm is a workaround for odd VCL architecture: it assigns object reference before calling its constructor, so that you can use global variables like "Form1" within FormCreate handler without getting a segfault. But doing so is bad, extremely bad practice...

Ah, so that explains the weird code in Lazarus's
Application.CreateForm(). Calling .NewInstance() and then later calling .Create(). :-) Thanks for the explanation.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email