[lazarus] lazarus debuging???

Michael.VanCanneyt at Wisa.be Michael.VanCanneyt at Wisa.be
Mon Dec 23 10:06:07 EST 2002

On Mon, 23 Dec 2002 matooo at email.si wrote:

> Quoting Michael.VanCanneyt at wisa.be:
> >
> >
> > On Mon, 23 Dec 2002 matooo at email.si wrote:
> >
> > >
> > > m.
> > >
> > > P.S. what's with datasource and db. Since M$ seems to be buying
> > Borland, I need
> > > Lazarus urgently in more finished base. So if no one has done yet I'll
> > be
> > > available in about two weeks, but I think there is a better way to do
> > it than
> > > Borland did it.
> >
> > Basic TDataset/TDataSource is functioning. TDataset decsendents exist
> > for
> > Mysql,Interbase and DBase; Oracle,PostGreSQL and ODBC should be easy to
> > add as well as we have 'plain' interfaces for them.
> >
> > The code is tested - rudely. I would be very happy if you could do
> > stress-testing and communicate with me so we can fix or improve
> > things if needed.
> >
> > I've started a design based on TDatabase/TTransaction/TQuery, but I
> > haven't
> > been able to finish that yet. I hope to start this in a month or two.
> >
> > Also, I recently found an open source alternative to MIDAS (HyperBase)
> > -
> > and this is a gem which still needs including. Meaning that a
> > TClientDataset
> > descendent of TDataset should be written.
> >
> > As for a 'better way' than Borland did it: As long as you don't break
> > compatibility, please. But there is tons of DB-aware code out there
> > (just search Torry's pages or DSP) and it would be a shame not to be
> However you look at it. Some things are a real shame to embrace them. I just
> don't understand why TEdit, TDBEdit, TXXXEdit... (but maybe is that just me) and
> so on. Borland has just made Datalinks one step too late. Wouldn't it be easier
> if one component could be data-aware, simple or anything aware. Not needing to
> change component if you'd need a little different purpose.

Maybe, but then this would force all DB code in each and every application,
even if they don't use it. This is the VB approach.

The Delphi approach is more modular and easier to understand.

> Stupid component hierarchy is the main reason why all of my friends that used
> Btrieve can't change to anything other than that (or they ever will, but believe
> me they would like).

I don't see the connection.
If you use standard Delphi controls, the DB engine used has nothing to do with
the GUI layer used. If you use some proprietary format type IBObjects, then
you have problems of course.

At work we switched from Btrieve to Access to Interbase, without problem.

> plus if you need a DB equivalent you would probably need just a name compatibility.
> type
>   TDBEdit = class(TEdit);
>   end;

The name is not the issue, of course.

And anyway for each 'big' application that has 20 or more forms, I would recommend
making a private descendent of each and every control used and only use
these controls. Besides being able to introduce customized behaviour,
his allows you to switch to another set of underlying controls at any
later time without loosing properties or methods.
One recompile should be sufficient to use the new set of controls.


More information about the Lazarus mailing list