Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread DBGrids
Sun, Apr 1 2012 4:37 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

I'm (yet again) looking at DBGrids. The reason this time is the replacement in my app of TMS AdvStringGrid with a nlhSGTable/datasource/dbgrid combo. I'm going to have to either enhance my DBGrid (based on MSDBGrid) or buy a new one.

I do not want a stringgrid descendant I'm looking for a dbgrid descendant. I do not want to operate in unbound mode) So far my choices see to be X-DBGrid (http://www.x-files.pl/) and rDBGrid (http://www.rosinsky.cz/delphi.html).

Anyone have any comments about these two or other suggestions to offer.


Roy Lambert
Tue, Apr 10 2012 7:51 AMPermanent Link

Adam Brett

Orixa Systems

>>Anyone have any comments about these two or other suggestions to offer.

I don't know either of your suggestions. I have plumped for the DxGrid, from Dev Express.

It is a completely amazing component, a vast multifaceted monster, or a ridiculously over engineered piece of software depending on your perspective.

Note it doesn't even really class as a "DB" Grid as you can connect to to just about any iterate-able data ...

I have written my own descendent class which hides most of the features, and it works amazingly well.

Drawbacks:

1. Your EXEs swell to 30meg (no I am not joking: 30meg!!! ... when I was a student my computer science department had a 10 meg hard-disk.)

2. Its not cheap.

3. You will have to spend a day getting your head round it. for example, even doing simple things like changing the colour of a row of column involves instantiating additional "Style" objects & then setting properties on these child-objects & attaching them to the appropriate grid-column ... But once you get these, you can build style sheets & call them up really easily.

Advantages:

1. Every possible built in feature you could ever imagine plus hundreds which you are surprised and pleased by, plus a couple of hundred more which seem either insane or foolish.

2. Basically it is possible to build an entire GUI around this 1 component if you want to, it will even display TChart and animations within the bounds of the grid-cells, allows all sorts of drill-down, filtering grouping ....

3. The Help & Support is bloody brilliant, so any question you ask will be either have been answered already or will be answered with in 24 hours of posing it.
Tue, Apr 10 2012 9:27 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Adam

Thanks for your suggestion. I won't be taking it up for a few reasons:

1. Price (remember I'm a hobbyist so I'm the only one paying for this)
2. I want a DBGrid descendent.  I've had bad experiences with stringgrid descendents. I know the reason I'm looking for a replacement for TMS' ADVStringGrid but I've written my own "stringgrid table" so things I used to display/edit in a stringgrid will now be stuffed into the DBGrid.
3. StringGrids only make good DBGrids when used in non-paging mode (ie load the data and disconnect).
4. I'm not a fan of "the application in a grid" type of systems which is what these types of grids seem intended for.

>It is a completely amazing component, a vast multifaceted monster, or a ridiculously over engineered piece of software depending on your perspective.

Either of those, and as well as exe size it also has an effect on speed. As part of my development of nlhSGTable (my stringgrid table) I did a few tests populating the grid. I tested nlhSGTable in its fast mode (just stuff data into a stringlist) and ElevateDB and AdvStringGrid (with beginupdate/endupdate). I forget how many rows (10, 1,000, 10,000 or 100,000) nlhSGTable took c0.1seconds, ElevateDB c2.3seconds and TMS AdvStringGrid c2.4seconds. I thought something had gone wrong so used nlgSGTable's FldCells (equivalent to stringgrid.Cells) and that pushed it up to 0.2 seconds.

>Note it doesn't even really class as a "DB" Grid as you can connect to to just about any iterate-able data ...

Yup like any string grid

>I have written my own descendent class which hides most of the features, and it works amazingly well.

Yeah otherwise you get lost in them. I just spent a while finding where a particular colour setting was in a AdvStringGrid because I wanted to use the same colour elsewhere.

>Drawbacks:
>
>1. Your EXEs swell to 30meg (no I am not joking: 30meg!!! ... when I was a student my computer science department had a 10 meg hard-disk.)

My exes are already 30Mb - mind you that's in development mode and includes MadExcept and full debug FastMM

When I was in a "proper" job and Head of IT at Imperial Foods I bought the company's first PC. Single 360Kb floppy. The second one had a 5Mb hard disk (it and epson dot matrix printer was c£5k)

>2. Its not cheap.

One reason I won't be buying Smiley

>3. You will have to spend a day getting your head round it. for example, even doing simple things like changing the colour of a row of column involves instantiating additional "Style" objects & then setting properties on these child-objects & attaching them to the appropriate grid-column ... But once you get these, you can build style sheets & call them up really easily.

I know. TMS stuff has much the same problem, and when I bought it complexity was complemented by duff documentation.

>Advantages:
>
>1. Every possible built in feature you could ever imagine plus hundreds which you are surprised and pleased by, plus a couple of hundred more which seem either insane or foolish.

I don't regard that as a benefit. You're paying for that in terms of product price, learning curve, executable size, application performance, and a nice environment for bugs to nest in!

I read an article on TheReg today - someone did a report on W3.1 - 20 years on. One question he asked was how did Word go from its early versions to the bloated monster it is now. My guess at the answer is that as something like the DevEx grid its got everything but the kitchen sink in it.

Another aside. I've been through this exercise already with TMS' DBAdvGrid and AdvOfficePager. With replacing the DBGrid I saved just over 1Mb from the exe and picked up (gut feel) around 10% speed, and was able to control the tables and queries displayed properly. With the page control the cumulative savings came to around 2Mb but no more improvement in speed.

>2. Basically it is possible to build an entire GUI around this 1 component if you want to, it will even display TChart and animations within the bounds of the grid-cells, allows all sorts of drill-down, filtering grouping ....

If I ever develop applications where the entire system can be embedded in a grid it would be worthwhile. Unfortunately, the systems I build are data and display rich and it would be painful trying to stuff one into a grid. I could do it but I wouldn't enjoy it and neither would the few users they have.

>3. The Help & Support is bloody brilliant, so any question you ask will be either have been answered already or will be answered with in 24 hours of posing it.

Always important.

Roy
Fri, Apr 13 2012 1:59 AMPermanent Link

Steve Gill

Avatar

Hi Adam,

<< .....I have plumped for the DxGrid, from Dev Express..... >>

Me too. After using TopGrid for many years it was abandoned by the developer. I had to find a grid which would support the same type of features, plus more.  After evaluating several grids I finally coughed up a substantial amount of money for the DevExpress QuantumGrid.  

It is an amazing grid that has a lot of flexibility.  Expensive and maybe a bit of overkill, but nothing else had the features that I required.  And the great thing is, as I enhance my applications I find that the grid already has the functionality that I need for the new features.  Quite often in the past, I had to dump grids because my apps had outgrown them (which was an expensive exercise itself).  Haven't had that problem yet with QuantumGrid.

Steve
Image