[fpc-devel]TDataModul

[Michael.VanCanneyt at Wisa.be]

On Sat, 28 Dec 2002, [ISO-8859-1] Sebastian Günther wrote:

> Michael.VanCanneyt at wisa.be schrieb:
> >
> > In that case the name 'TDataModule' is not really representative.
> > TComponentModule might be a better name. And then create a TDataModule
> > descendent.
>
> And what should be the difference between these two classes?

I would remove the Width/Height/Top/Left streaming code from
TComponentModule; Also, web stuff and so doesn't necessarily need
TDataModule, it just needs 'components'.


>
>
> > As far as I can see, we need a function that returns a stream which contains
> > the component data. All the rest can be handled in a 'global' way; Only the
> > instancing of the stream is specific to the kind of streaming used.
> >
> > For lazarus, this would probably be a memory stream which is instantiated
> > from the lazarus resources. For fpgui, this would be a file stream which
> > points to the .dfm file. A combined approach is possible, of course.
> >
> > So, basically we need a callback which returns the appropriate stream to
> > instantiate the component ? Do I undertand this correct ?
>
> No, we need exactly this. I propose to add a callback similar to
> FindGlobalComponent etc.
>
> type
>    TReadComponentCallback = function(const AClassName: String; AInstance:
>      TComponent): Boolean;
> var
>    ReadComponent: TReadComponentCallback;
>
> (just a proposal)

The reason I propose not this is that there is still quite some
general-purpose code in InitInheritedComponent, which should not be handled
by the callback IMO. After studying it a bit, I decided that the system
specific boils down to creating the right stream; All the rest is
general-purpose (globalloading list handling etc.).

> And, you didn't answer this yet :) : Should we move the folders unit to
> the FCL or not? I think it will be quite useful for different things

I'm sorry, I didn't catch this ? Where is this unit ?
I haven't found it in any directory on my harddisk ??

Michael.