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

[Frank Church]

On 16 November 2010 08:35, Bo Berglund <bo.berglund at gmail.com> wrote:

> On Mon, 15 Nov 2010 16:36:38 -0500, Steve Smith <stevie at collector.org>
> wrote:
>
> >Message: 5
> >Date: Mon, 15 Nov 2010 16:32:34 +0100
> >From: Bo Berglund <bo.berglund at gmail.com>
> >Subject: Re: [Lazarus] When do I need a component rather than a plain
> >    object?
> >To: lazarus at lists.lazarus.freepascal.org
> >Message-ID: <ruj2e61613s285b5pj9ieitbf2qld9d56k at 4ax.com>
> >Content-Type: text/plain; charset=us-ascii
> >
> >On, 15 Nov 2010 16:32:34 +0100, Bo Berglund <bo.berglund at gmail.com>
> >wrote:
> >
> >> According to what I have read in the WIKI you only install components
> >> into Lazarus if they are visual and you really need them to be part of
> >> a visual form.
> >
> >> In all other cases you should not install a component in the IDE,
> >> instead you instantiate the objects from that component in code.
> >
> >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?
> 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).
>
> >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.
> 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.
>
> We stopped this and instead create normal classes based on TObject.
> These can then be checked out into a project source tree very much
> apart from the IDE folder tree. Here we have full control and can be
> sure that we can tag all project files so that we can get back to an
> old state when we need to fix user bug reports.
> And the classes used in a project will be easily updated to the latest
> state as part of the general project source update from CVS (yes we
> use CVS...).
> In the component case we always had to "know" that we also needed to
> update the IDE components in a different place to get the latest and
> we could not tag the project in one place and be sure that we tagged
> all sources...
>
> Now that we are stuck with a lot of component stuff from old times we
> have stopped installing them in the IDE. We just use tham as normal
> classes and we create them as needed in the project start code and it
> works just fine. The sources are checked out into each project that
> use them and this means that a tag on the project will hit them too.
> So we can recreate the exact situation for a user version that has a
> bug and fix it.
>
> Of course this holds for all components tha are non-visual, which most
> of ours were. But we do have stuff that are visual too, and here we
> have to install in teh IDE but then (in Delphi) we make sure that
> there is no global path to the component sources so we can add the
> component sources to the project module and check out as usual. Then
> we set the project search path to include these local copies. It seems
> to work but is a bit of a hassle.
>
> --
>
> Bo Berglund
> Developer in Sweden
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>



I realized the wisdom of Bo's approach to creating components at run-time
and setting the properties in code only 2 days go.

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.

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

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.

-- 
Frank Church

=======================
http://devblog.brahmancreations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20101116/3bfbfd96/attachment-0003.html>