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/ _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
