[lazarus] lazarus debuging???

[matooo at email.si]

Quoting Michael.VanCanneyt at wisa.be:

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

nope, as I did it.
TBaseDatasource is just a dummy datasource (no db connection at all), just dummy
fieldlinks, that connect to datasource functionality. no dbdatasource, no
dbcode. That's the mistake I said datasource is DBOnly??? why when it could be
used as any structure source. 

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

only connection to I/O is datasource, and using specialized datasources makes
you available to change access in runtime. But I'd probably better make a demo
someday in this month and send, it would explain more

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

That's an option too, but I stopped using it long ago, perhaps demo will provide
better explanation

> Michael.
> 

m.

-------------------
http://www.email.si