Hi,

If a table is defined with a field VarChar(120), the DBGrid seems to size that column for 120 chars, even though the longest field item might only use 20 chars.

Is there an option for the DBGrid to automatically resize its columns to fit the data?

I'm working with Lazarus Data Desktop and use it to execute queries, but the columns are way to wide considering the data in each column. So I have to scroll a LOT, or resize the columns after each query. Both cases are very annoying!

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

Is there an option for the DBGrid to automatically resize its columns to fit the data?

Anybody know if TDBGrid can do this? If so, what properties need to be set?

Here is a bug report regarding this issue. The report also contains two comparison images showing the difference: FlameRobin vs LazDataDesktop executing the exact same query and the default result data grid generated.

http://bugs.freepascal.org/view.php?id=14006

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

En/na Graeme Geldenhuys ha escrit:

TRxDBGrid can do it, however (and obviously) it has to iterate through all the records to find the longest one.

BTW, I'm all for having all the nice options in TRxDbGrid in the standard TDBGrid (though I'm not sure the license allows to copy them verbatim), my suggestion is only if you want a solution *now*

Bye

Luca Olivetti wrote

TRxDBGrid can do it, however (and obviously) it has to iterate through all the records to find the longest one.

Well, it has to iterate through all the records anyway to paint the data in the cells. So the TDBGrid could simply keep track of the longest cell value in each column and size the width of each column appropriately.

So does this mean the TDBGrid cannot or doesn't have this feature at the moment?

BTW, I'm all for having all the nice options in TRxDbGrid in the standard TDBGrid (though I'm not sure the license allows to copy them verbatim), my suggestion is only if you want a solution *now*

It's definitely not a TRxDBGrid specific feature. FlameRobin has that feature in its grid is definitely not written in Object Pascal. HTML tables also have that feature by default and again I don't know of a single web browser written in Object Pascal (excluding HTML viewing components).

So I cannot see any license issues implementing this in TDBGrid.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

En/na Graeme Geldenhuys ha escrit:

I don't think it has

My comment was about verbatim copying of /code/ from TRxDBGrid to TDBGrid

Bye

Luca Olivetti wrote

My comment was about verbatim copying of /code/ from TRxDBGrid to TDBGrid

OK. Verbatim copying is 99% of the time not a good idea anyway. ;-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

hunh? why iterate thru? doesn't it already have to process each row when they come in from the server? that would be the time and place to do this width setting, in my old school procedural mindset...

--- El jue 18-jun-09, waldo kitty escribi?:

The grid only knows about the records that fit in its rectangular area, for this limited set of records the grid could autosize columns without performing additional fetches.

AFAIR the dataset caches only 10 records by default. Retrieving all records from dataset works only nice for some dbengine-local/remote combinations, nobody likes to wait too much while the grid retrievs thoudsand o millions of records from remote server just to find what is the best column size. Moreover, some databases provide cursor with forward only transversal even when grid could retrieve everything it doesn't have functionality to cache records locally. So the final decision need to be made by the programmer through options.

So what are the options?, one could ask the grid to do autosizing with it's limited set of records, another, it could use first-next to browse all records, it could do the later using some amount of records only, etc. Once autosizing is made should it try again as new records become available until eof, ....

ideas?

btw, I also found annoying to have so big column sizes, it seemed to me that previoulsy it didn't do this, but I know it wasn't done intentionally in the grid :)

Jesus Reyes A.

?Obt?n la mejor experiencia en la web! Descarga gratis el nuevo Internet Explorer 8. http://downloads.yahoo.com/ieak8/?l=mx

Jesus Reyes wrote

So what are the options?, one could ask the grid to do autosizing with it's limited set of records,

That was my thinking as well. If the grid only fetches and displays 10 records at a time, then start with only those 10 records - to calculate the best fit with of each column.

As the user scrolls the grid and more data gets fetched, so the column with calculation continues and the width adjusted. Any half descent programmer would know not to retrieve a couple million records and try and display it in a grid - talk about data overload! :-)

Alternatively, if the idea of columns being resized as scrolled is disliked by most, then I think even by only using the first 10 cached records to calculate a more sane column width is better than the huge column widths currently in the grid. So even if the user scrolls and some data doesn't fit, it at least means most data fits and only a select few columns would need to be resized by the user. It's still a lot better than having a grid and only seeing one column (very wide) that fills the grid width and only a small about of actual text in that column (see the screenshot of the bug report I mentioned).

btw, I also found annoying to have so big column sizes, it seemed to me that previoulsy it didn't do this, but I know it wasn't done intentionally in the grid :)

And it seems even worse if UTF8 charset is used in the database (I'm using Firebird DB) and you have columns defined as CHAR(x). But I am glad to hear I am not the only one finding this annoying.

I did a small usability study on LazDataDesktop to see if it could replace other similar software (like FlameRobin). There was a few issues remaining, but the grid column widths drove me nuts very quickly.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/