[Lazarus] When do I need a component rather than a plain object?

Steve Smith stevie at collector.org
Tue Nov 16 15:44:58 CET 2010


On, 15 Nov 2010 16:32:34 +0100, Bo Berglund <bo.berglund at gmail.com>
wrote:

> What I was getting at is this:
> Any component that you want to put visually on a form requires that
> component to be installed in the IDE, which also means that its
> sources are stored within the Lazarus own folder tree.

There is NO requirement for a visual component to be placed on the
IDE component palette.  You place a component on the palette to
provide design time access to it in the forms designer.  This access
has nothing to do with a component being a visual or non-visual one.
You can instantiate a TTimer or a TListBox from code if you wish.

The source can be anywhere.  The directory needs to be in the list of
directories searched for units in the Compiler Options dialogue.

> But in a software development environment with many developers working
> on many projects where these components are used there is a problem of
> ensuring that the components are up to date within the projects.

There is indeed, it is called "Packages"

> We faced this many times when developing with Delphi because we fell 
into
> the trap of creating "components" instead of ordinary classes for
> stuff that had no visuality in teh programs. It was sort of a
> convenience that you could drop for instance a logging component onto
> your main form and then set its properties in the designer. But the
> component had no visual part and should not have been a component in
> the first place.

It can be much more than a "convenience".  It gives you the possibility 
of
providing design-time support for your component.  eg the Fields Editor
for a database table.  Or the Action Editor for TAction for example.  
It also
provides the support for things like the addition of event skeletons in 
the
code editor.

> We stopped this and instead create normal classes based on TObject.

Just because you don't include it in the IDE doesn't mean it can't be a
TComponent descendent (or TControl or TButton descendent).  You are
free to write a listbox descendent and NOT include it in the IDE.  It 
can be
the easiest option if you are writing a new component, visual or non-
visual, for example.

On Tue, 16 Nov 2010 09:45:49 -0000, Frank Church <vfclists at gmail.com>
wrote:

> I overwrote some of my newer code with older code, and although I
> restored the *.pas from git, I forgot about the*.lfm where the SQL 
was
> stored. It was only hours later that I realized the the update code 
was
> in the components that I restored it.

Bo's approach doesn't solve this problem;  You still need the same 
files
for the Visual Components, and what about include files, resource 
files,
image files etc.  If you use a source control product, you have to 
ensure
that you restore ALL the files required, you can't pick and choose.
Hopefully, git has an option or options to do this for you, otherwise 
it's
a waste of space.

> Initialzing non-visual components from form properties is an evil 
which
> is best avoided.

Why limit your ire to non-visual components?  If it's evil for 
non-visual
components, surely your ire needs to be redirected to all components.
Why should I have to initialise TTimer in code but I can use the forms
designer for a TButton.

> It will be good if Lazarus can generate the source code to initialize
> components at the start of a program, rather than stream them in, 
hopefully
> in a future version. It makes revision control much easier, a lot more
> transparent.

God's teeth!  The unit for the form would, potentially, be huge!  
Again, it doesn't
help with source control either.  You still have to manage all the 
other non-
pascal files in your project such as include files, resource files, 
images etc.
If your source control package can handle these, it should be able to 
handle
form files too.  If it can't, you should be shopping for a new one.




More information about the Lazarus mailing list