View Issue Details

IDProjectCategoryView StatusLast Update
0002317JEDI VCL00 JVCL Componentspublic2005-04-12 03:02
ReporteranonymousAssigned Toobones 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.00 BETA 2 
Target VersionFixed in Version3.10 
Summary0002317: jvdbgrid alternate autosizecolumn logic
Descriptionjvdbgrid's autosizecolumns logic doesn't work correctly with nonstandard scrollbar size.
Additional InformationWhen using a jvdbgrid with autosizecolumns=true and nonstandard (i.e. larger than usual) scrollbar size (set from windows display control panel), the grid will show two different results :
- when not in focus, the last column will appear larger than the available client width, so a horizontal scrollbar will appear on the bottom of the grid.
- when in focus, the resize logic will appear to work correctly, and the horizontal scrollbar will disappear.

When showing a form containing the grid in a non-modal state, an annoying redraw (and resize) will occur everytime the grid receives focus.

The code responsible for this resides in JVDBGRID.PAS, procedure TJVDBGrid.DoAutoSizeColumns.

Here's an alternative approach that worked for me :
...
if AutoSizeColumnIndex = JvGridResizeProportionally then
      begin
          //1st pass: get total width
          sugiTotalWidth := 0;
          for i:=0 to columns.count-1 do begin
              if (columns[i].visible) then begin
                  sugiWidth := columns[i].width;
                  if (sugiWidth) < 80 then sugiWidth := 80;
                  if (sugiWidth) > 200 then sugiWidth := 200;
                  
                sugiTotalWidth := sugiTotalWidth + sugiWidth;
            end;
          end;
          //2nd pass: resize...
          for i:=0 to columns.count-1 do begin
              if (columns[i].visible) then begin
                  sugiWidth := columns[i].width;
                  if (sugiWidth) < 80 then sugiWidth := 80;
                  if (sugiWidth) > 200 then sugiWidth := 200;
                  
                  //normal calculation...
                  columns[i].width := trunc(TotalWidth*sugiWidth/sugiTotalWidth);
              end;
          end;
      end
...
The numbers 80 and 200 is empirically chosen. It appears that the original authors intend to use the MinColumnSize and MaxColumnSize properties to achieve the same effect, but the implementation still exhibit the "too-narrow-column" effect. (For example, if you have three columns :
- column_a, string, 1000 characters
- column_b, string, 500 characters
- column_c, integer
then the third column will always appear as too narrow, only several pixels wide.




TagsNo tags attached.

Activities

user72

2004-11-15 14:56

  ~0005636

So why not just set MinColumnSize to 80 and MaxColumnSize to 200 instead of hardcoding it?

anonymous

2004-11-15 20:34

viewer   ~0005638

Yes. Instead of hardcoding it, it would be better to make it into user-modifiable properties, but it cannot be the same as MinColumSize and MaxColumnSize, since these affect the resizing logic in a different way.

See the last paragraph of the original note for a description.

obones

2004-11-30 04:39

administrator   ~0005776

Reminder sent to: user72

What should we do about this issue?

user72

2004-11-30 12:04

  ~0005793

> What should we do about this issue?
I'd relay it to Fred. I think he's the one best suited to make the decision.

Personally, I don't have any issues with the solution as long as the min/max values aren't hardcoded.

anonymous

2004-12-06 07:51

viewer   ~0005834

Do we have to respect the min/max values when we perform an AutoSize? Because these values bring about two problems:
- if (min. width * nb. of columns) > total width -> result too large
- if (max. width * nb. of columns) < total width -> result too small

I suggest:
1 - In the above cases, min. and max. values are not respected. In any other case, they are respected.
or
2 - An error message is raised when we are in the above cases ("Settings not compatible with AutoSize").

Fred

obones

2005-04-01 05:52

administrator   ~0006808

I'd go for option 1.

obones

2005-04-12 03:02

administrator   ~0006924

This is now in CVS, option 1 has been chosen.
Thanks to Fred and Dom.

Issue History

Date Modified Username Field Change
2004-11-15 12:16 anonymous New Issue
2004-11-15 14:56 user72 Note Added: 0005636
2004-11-15 14:56 user72 Status new => feedback
2004-11-15 20:34 anonymous Note Added: 0005638
2004-11-30 04:39 obones Note Added: 0005776
2004-11-30 12:04 user72 Note Added: 0005793
2004-12-06 07:51 anonymous Note Added: 0005834
2005-04-01 05:52 obones Note Added: 0006808
2005-04-12 03:02 obones Status feedback => resolved
2005-04-12 03:02 obones Resolution open => fixed
2005-04-12 03:02 obones Assigned To => obones
2005-04-12 03:02 obones Note Added: 0006924