[lazarus] TStringGrid

[Michael Van Canneyt]

On Mon, 9 Sep 2002, Jeff Wormsley wrote:

> *********** REPLY SEPARATOR  ***********
>
> On 9/9/2002 at 11:35 PM Michael.VanCanneyt at Wisa.be wrote:
>
> >No, because also the structure definitions (records etc) have changed,
> >and we cannot change these at runtime.
> >If it was only the DLL procedure entry points, this could be done, but not
> >if the structures change. It's a problem that will occur with all C
> >libraries. Annoying, but nothing we can do about it.
>
> Hmm, I suppose I'll have to diff the code to see what you mean.

The internal MySQL types have changed.

> I've used
> some code that provided seamless use of several versions of Paradox, dBase
> and Clipper with only one codebase, and the record structures used there
> were different.  Of course, this was local tables, not client/server.
>
> I suppose also, you are refering to a native access implementation, not a
> TDataset descendant, which would encapsulate much of the lower levels of
> functionality, and thus could more easily support multiple versions.  I
> don't know how much you've messed with Delphi's TDataset descendants,

I have written several myself, and I implemented the FPC version of
TDataset, so I assume I know what I'm talking about.

> but
> once you get used to the hoops you have to go through to write one, they
> are very handy things to have around.  Yes, you are abstracted away from
> the lower levels, and so may be sacrificing some of the power, but the
> common interface and ability to switch backends almost on the fly can be
> very useful.

I could not agree more. The only reason why FPC doesn't offer more of
this is lack of time.

>
> I guess it just seemed odd in these days of component based programming
> that something wouldn't be able to support multiple backends without
> recompile, or at least a graceful abort when not compatible.

Feel free to modify the sources to this end. It's open source, after
all.

In general, I must say that the offers for support for database
functionality have been limited not to say almost non-existent.
Which is a pity, since about 95% of corporate programming is
database programming.

But, given time, we'll make it there too. I have ideas on how to do all
this, just the time to implement them is lacking. I suppose that goes
for many people on this list :-)

Michael.