[Re: [lazarus] How are we going to store component data?]

[Michal Bukovjan]

Hi,

I think this is not much usable, because :

1} The storage mechanism starts at TForm. This caused a lot of pain in Delphi,
because for compound components, it is highly preferable that a TComponent
class can remember its state.

2} It is for design-time only. While this may be enough for RAD, the Delphi
system allows for much more flexible run-time behavior, you can stream the
component (and its children) to an arbitrary stream, send over whatever you
like {pipe, file, DCOM/CORBA connection, shared memory) and make use of the
component state in another instance, or another app altogether. Not to mention
storing component's state in a database BLOB !

While the binary stream-out may not be the best solution (i.e. XML might be
better), I suggest we use some sort of streaming technique.

3) Using the below system, reading of larger pixmaps, sound clips or whatever
binary data could be real fun :-(

Just my thoughts,

Regards,

Michal Bukovjan


"Michael A. Hess" <mhess at miraclec.com> wrote:
> michael at tfdec1.fys.kuleuven.ac.be wrote:
> > 
> > > Or are we going to have the RAD generate FCL code that is included
> > > into the file via an {$I ...} statement at the appropriate place?
> > 
> > This is a possibility which you can consider, and which would be very
> > fast; you could make a TForm abstract method called :
> > 
> > TForm.CreateDesignedForm;virtual;
> > 
> > begin
> > end;
> > 
> > Which you override in the .dfm form:
> > 
> > TForm.CreateDesignedForm; override;
> > 
> > begin
> >   SetBounds(X,Y,W,H); // place form
> >   MyButton:=Tbutton.Create(Self);
> >   // and so on
> > end;
> > 
> > At the end of TForm.Create you then do a
> > 
> >   CreateDesignedForm;
> >   If Assigned(OnCreateForm) do
> >      OnCreateForm(Self);
> >   // Form Creation Complete.
> > end;
> 
> This is exactly what I had in mind. I personally would like to lean
> toward this directly. It seems to give us more flexibility and it
> doesn't rely on compiler features to implement it.
> 
> On the good side it would mean you could manually go in a tweek a
> components location or some other aspect. The downside is that you could
> go in a tweek a component location or some other aspect BADLY.
> 
> It would only require a simple text parser to read in the settings for
> the RAD and editing the same would be just as easy.
> 
> If we go the resource route we need to have routines in the IDE that can
> write and interpret the file data. The compiling would then have to deal
> with the binobj stuff and would we get into platform issues. Next the
> code would have to open the resource part of the file to get the data to
> setup the form.
> 
> When it all comes down to it I like the idea of a code generated file
> that is loaded with an {$I...} command. Any other opinions?
> 
> 
> -- 
> ==== Programming my first best destiny! ====
> 
> Michael A. Hess      Miracle Concepts, Inc.
> mhess at miraclec.com   http://www.miraclec.com
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.