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

Michael A. Hess mhess at miraclec.com
Wed Jul 21 13:15:55 EDT 1999


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






More information about the Lazarus mailing list