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

[Michael Van Canneyt]

On Thu, 3 Jun 2010, Mattias Gaertner wrote:

> On Thu, 3 Jun 2010 20:38:26 +0200 (CEST)
> Michael Van Canneyt <michael at freepascal.org> wrote:
>
>>
>>
>> On Thu, 3 Jun 2010, Graeme Geldenhuys wrote:
>>
>>> On 3 June 2010 17:24, Michael Van Canneyt <michael at freepascal.org> wrote:
>>>>
>>>> You must override GetChildren.
>>>>
>>>> In the LCL, TWinControl overrides GetChildren to write child controls.
>>>>
>>>> It is documented.
>>>
>>> But why is GetChildren needed? Why can't TWriter use ComponentCount
>>> and Components[] like I have done in the TraverseComponents()
>>> recursive procedure?
>>
>> Because Borland decided otherwise.
>>
>> Actually, there is a good reason: some components create internal
>> components they own, and which they don't want to have streamed.
>> The 'GetChildren' allows you to control what gets streamed and
>> what not.
>
> For example a TOpenDialog is not in Controls, so it must be put into
> GetChildren.
>
>
>>> "  Adds component to children list which have no parent.
>>>    (TWinControl only lists components with parents) "
>>
>>
>>>
>>> Is that still true?  In fpGUI I set Owner and Parent. What is
>>> different in fpGUI (compared to LCL or VCL) is that Owner = Parent,
>>> always. I don't see a need for them to be different - one widget can
>>> just as easily manage the lifespan of another widget. Re-parenting a
>>> widgets also works in fpGUI, by simply transferring the ownership to
>>> the new parent widget (inserting into Components[] array).
>>
>> In LCL the owner is always the form. Otherwise the form variables
>> would not work.
>
> Yes, and no.
> Think about Frames, Ancestors and special created components (e.g.
> TSynEdit creates some components owned by itself).

I deliberately didn't mention these cases ;)

Michael.