[fpc-pascal] TFPColor vs TColor

[Mattias Gaertner]

On Tue, 5 May 2009 20:05:34 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> On Tue, May 5, 2009 at 6:08 PM, Mattias Gaertner
> <nc-gaertnma at netcologne.de> wrote:
> >
> > There are ways to use a single include file. For example:
> >
> > ---------
> > {$I unit1.lfm}
> >
> > constructor TForm1.Create(TheOwner: TComponent);
> > begin
> >  RegisterComponentInit(@InitTForm1,TForm1);
> >  inherited Create(TheOwner);
> > end;
> 
> 
> Where is RegisterComponentInit() defined?  I search all of Lazarus and
> FPC 2.2.5 and couldn't find a definition.

Sorry. It's only pseudo code. The functions do not exists yet. Just to
demonstrate how it could look like.

 
> > How are images and other arbitrary data saved to the source?
> 
> Currently they are declared as byte array constant. I have a small
> little program that convert images using bin2obj

ok


> > *The lfm files can become quite large. Just put 100 components onto
> > a form and add some glyphs. There will be several thousand lines of
> > automatically generated code in your unit.
> 
> Thousand lines in a lfm file compared to a pas file. Doesn't matter to
> me much - yet.

Well, power users don't scroll, they fly via shortcuts.

Casual users use PgUp/PgDown.

 
> > *Word completion will show you a lot of junk.

If we use numbers instead of strings to store the binary data, then
word completion and search/replace will work properly.


> > *when the IDE searches a component with the name 'Form1' it has to
> > read in worst case all source files in the search path completely.
> > This
> 
> I'll investigate these two further. But so far it hasn't been an
> issue for me.

I guess, the question is not, if the include file should be
supported, the question is, if optionally lfm-in-source should be
supported.


Mattias