[fpc-pascal] WriteComponent not outputting a hierarchy of components?

Graeme Geldenhuys graemeg.lists at gmail.com
Thu Jun 3 23:59:27 CEST 2010


On 3 June 2010 22:33, Michael Van Canneyt wrote:
>>
>> Well, isn't that what the 'stored' specifier could be used for too, to
>> know if a property should be stored or not.
>
> No, because there may not be a property. You can perfectly have a child
> component without a property to access it.

Sorry, I didn't mean for storing at the property level, I meant a
public boolean function (eg: function MustBeStored: boolean;
override;) at component level that TWriter could use to query if it
should store that component or not. Then at the component end you
could simply override MustBeStored and return false (default could
have been True - meaning by default it is stored/streamed).

This seems much simpler than the GetChildren idea and duplicating a
loop through components and various class levels. But I guess Borland
developers smoking whatever they did at the time, couldn't think of
anything better. And now we all have to live with that fate in FPC
too. :-/


> Personally, I think that this is mixing 2 concepts:
>
> Owner/Owned is a matter of lifetime and memory management of objects.
> Parent/Child is a visual relationship.

Two concepts that work exactly in parallel, so one property could have
served both purposes. And as such a lot of code in LCL and fpGUI
components proves, one TComponent (widget) can just as easily manage
lifetime instead of TForm. And the hierarchy of lifetime management is
exactly in parallel with the visual aspect too.

Again another botched idea from Borland.

Anyway, now we are detracting from my initial question. But I guess
this is yet another pointless issue I raise, because "delphi
compatibility" is going to be thrown in my face shortly.


> I once had a discussion about it with a Borland employee, and the way he
> made a point of it makes me believe there is a reason for it. We simply
> don't know it.

Like I said: No idea what they have been smoking. :)   If one can't
clearly describe the reason for some design, it probably means the
design is faulty. That would be something new either, Borland made
many mistakes.


To get back to the point. So must I now override GetChildren for every
single component in fpGUI that can contain child components and do the
loopy Components[] array thing?  Or do I only need to override
GetChildren in TfpgBaseForm - the top level window/container of all
other components? BTW: In fpGUI TfpgForm can act as both a TForm and
TFrame.


-- 
Regards,
  - Graeme -


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



More information about the fpc-pascal mailing list