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

Sven Barth pascaldragon at googlemail.com
Tue Nov 16 09:50:53 CET 2010

Am 16.11.2010 09:35, schrieb Bo Berglund:
>> You create and install a component, not because it is visual or
>> non-visual
>> but because you wish to use it in the visual forms designer in Lazarus,
>> just as in Delphi.  For example TTimer is not a visual component, but
>> because you wish to add it to the component palette and add it to your
>> form, it has to be a descendent of TComponent.
> Yes I understand what you say, but why not create the TTimer in code
> instead and not put it into a form where it will not show up in
> runtime?

You can do that as well. Nobody can stop you from creating a TTimer 
instance at runtime. The same is true for visual components as well. 
It's up to you what you prefer.

> Of course my discussion is not about the built-in IDE components but
> rather about self-developed non-visual components. These should NOT be
> installed in the IDE and the corresponding objects created in code
> instead. Then one gets more control (see below).

As said above you are free to do it as you want. Another one might love 
to put his/her non-visual components on the form and then the he/she 
must install the component in the IDE.

>> If you are creating a visual component it should be a descendent of
>> TControl or one of it's descendants.
>> TPersistent is the base class that implements support for the streaming
>> subsystem used by the forms designer and it's components to save their
>> properties in the form file.
>> If you don't wish any of these facilities, you can use TObject.
> 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.


Basically it works like this (in Lazarus):
- you create a package and register units that have components that need 
to be visible
- you can use this package without installing it in the IDE. Then your 
applications will find the units that are provided by the package, but 
you can't put them on a form
- you can install this package inside the IDE, so first part of the 
above statement still holds, but you can also put them on a form

This package can be anywhere on your system. The IDE will just compile 
itself with that package like it would compile a common application (did 
you already play around with Lazarus packages? I suggest you to do it :) 
). I myself have multiple 3rd party components in my version controlled 
package directory and at least the lNet components are installed in the IDE.

> 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. 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.

At my workplace we have a common svn repository with our 3rd party 
components. Those components are installed inside the Delphi IDE. We 
also have two other repositories where design time packages are located 
(our own components) and those can be installed in the IDE as well 
(switching between versions of our products doesn't work correctly, but 
I'm working on that).


More information about the Lazarus mailing list