See the sceenshot posted in the following Mantis report.

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

I would like to get rid of the "0" in the top left corner. It's very nice of TSringGrid to have the automatic option of adding row numbers, but I really don't think it should add the "0" in the top left automatically.

Anyway, how to I get rid of it? Because cell (0,0) seems to be the cell editable by the user, not the cell in the column header (fixed row and fixed column).

Regards,
- Graeme -

0,0 normally is the top left cell, even with fixed row/column.

Maybe the row-numbers option changes that. Try doing the row-numbering yourself.

Michael.

Michael Van Canneyt wrote

0,0 normally is the top left cell, even with fixed row/column.

That's what I thought too, but it didn't work like that when I created the "File Filters" screen. Below is the code I used...

Note I set RowCount = 1, which to me meant that the fixed row is now visible. When I set grdFileFilters.Columns[0].Title.Caption := '', it actually sets cell (1,0), the second column, to blank text.

So it seems Cell() and Columns() are inconsistent in meaning (column 0 not being the same thing) - or I simply don't know how to use the TStringGrid (which is probably true as well).

----------------------
procedure TFileFiltersOptionsFrame.Setup(ADialog:
TAbstractOptionsEditorDialog);
begin
  lblTitle.Caption := lisFileFiltersTitle;
  grdFileFilters.DefaultColWidth := 40;
  grdFileFilters.RowCount := 1;
  grdFileFilters.Columns[0].Title.Caption := lisFileFiltersName;
  grdFileFilters.Columns[1].Title.Caption := lisFileFiltersMask;
...
----------------------------

Maybe the row-numbers option changes that. Try doing the row-numbering yourself.

Jesus knows the StringGrid pretty well, so I'll wait a bit to see what he says. Otherwise I'll simply paint the fixed column (row numbers) myself - as you suggested.

Regards,
- Graeme -

Maybe the StringGrid should be patched to stop populating/painting the FixedRows columns?

-Fl?vio

2010/2/4 Fl?vio Etrusco :

Graeme, did you disable goFixedRowNumbering in your trial? If not, it didn't work because of this in
TCustomStringGrid.DrawCellAutonumbering:
...
if Cells[aCol,aRow]='' then

    inherited DrawCellAutoNumbering(aCol,aRow,aRect,aValue);

...

My suggested fix is replace in Grids.pas, line 8504:

>>

if (goFixedRowNumbering in Options) and (aCol = 0) and (FixedCols >=
1) and (aRow >= FixedRows) then

    DrawCellAutonumbering(aCol, aRow, aRect, IntToStr(aRow - FixedRows +1));

===

Best regards,
Fl?vio

Fl?vio Etrusco wrote

Maybe the StringGrid should be patched to stop populating/painting the FixedRows columns?

That's what it thought too, and just created a patch for it. :-)

So when Options includes goFixedRowNumbering, it skips the fixed row.

Now my next question is.... If FixedRows > 1, should the first non-fixed row start it's auto-numbering at 1 or what the (internal) row number is?

I would opt for starting the first non-fixed row always at 1 (human readable and understandable). What do others think?

See attached image if you did not understand what I meant...

Regards,
- Graeme -

Graeme Geldenhuys wrote

I would opt for starting the first non-fixed row always at 1 (human readable and understandable). What do others think?

Attached is my patch. This produces the results of the two grids on the right hand side (see previous email).

Regards,
- Graeme -

Fl?vio Etrusco wrote

My suggested fix is replace in Grids.pas, line 8504:

:-)
Great minds think alike. I just did one extra check for FixedRows = 0 and changed the value that gets painted as the row number.

See my other email for my patch.

Regards,
- Graeme -

--- El jue 4-feb-10, Graeme Geldenhuys escribi?:

Thanks, fixed in r23632 as a mix of your patch and Flavio's one. The additional FixedRows=0 didn't have any effect (I hope I didn't missed something).

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Jesus Reyes wrote

Thanks, fixed in r23632 as a mix of your patch and Flavio's one. The additional FixedRows=0 didn't have any effect (I hope I didn't missed something).

Flavio was right, FixedRows=0 wasn't needed.

Now that goFixedRowNumbering is fixed, what about the other problem?

"So it seems Cell() and Columns() are inconsistent in meaning (column 0 not being the same thing)"

I haven't double checked this after the goFixedRowNumbering fix, but I still think this is a separate issue and not affected by goFixedRowNumbering usage. Cells[0,0] doesn't seem to be equal to Columns[0].Title.Caption - if you have one fixed row and one fixed column. In that case Column[0].Title.Caption is actually referring to Cell[1,0] (note aCol = 1 here) - this is inconsistent and weird.

Is this done by design?

--- El jue 4-feb-10, Graeme Geldenhuys escribi?:

Is it an inconsistency?, yes and not.

One would expect that columns list correspond to physically grids columns but this is not true. This is not true for a dbgrid where underlaying grid cell 0,0 do not correspond to grid.columns[0].title.caption in case there is an indicator column (I might be wrong and hence I may have implemented this feature wrong :().

As the stringgrid columns support was based on how the columns works on dbgrid, it remains consistent that list column do not always correspond to physical grid columns. If a user that does not know this start coding and find that the caption on first custom column is not drawn on first grid column it does looks like an inconsistency, I agree too. So yes and not.

Btw, the column's caption should take precedence when drawing on corresponding grid cell.

This is not easy to fix, and also without causing headaches and unconformity by developers that currently have their applications running fine. So because of this and because I think this is not a major show stop, really I'm tempted to just document the fact and let the things like they are.

There is(are) already bug report(s) about this issue, I have not resolved them because it's still not a decided thing. In any case I don't expect to work on this before 1.0.

Jesus Reyes A.

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Jesus Reyes wrote

As the stringgrid columns support was based on how the columns works on dbgrid, it remains consistent that list column do not always correspond to physical grid columns.

I do not use DB-aware components at all, so I have no comparison other than to take your word for it. :-)

If it's by design, then I'm fine with it. It that case, the documentation for the Cells[] and Columns[] property must clearly state this rather interesting behaviour.

This brings me to an old argument that Cell[0,0] should rather be the first user selectable cell/row pair - which means it must exclude any fixed rows and fixed columns. The current behaviour of Columns[] property confirms this design. But that's a whole other topic to discuss. ;-)

Btw, the column's caption should take precedence when drawing on corresponding grid cell.

After I set the fixed row titles via Columns[].Title.Caption, I painted my content starting at Cells[0,0]. In the end I had double text over the fixed row. Was this not supposed to happen? I can supply a screenshot if that will help explain "double text".

--- El jue 4-feb-10, Graeme Geldenhuys escribi?:

No, double text should not occur, a screenshot helps but it would help better a bug report with a sample project :)

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Can I add something please? :-)

When setting RowCount:=0 (to clear the grid) and then RowCount:=5 it changes my FixedRowCount from 0 to 1. I don't want a title in this instance so I don't think the TStringGrid component should be getting all clever on me...

Thanks,

Paul.

This sure is a matter of taste, but wouldn't setting RowCount to FixedRows work for you?

-Fl?vio

Hi Fl?vio,

I'm using a TStringGrid for a checklistbox with two columns and don't ever want to see a title. So I set both FixedRows:=0 and RowCount:=0 in designer. Whenever I set RowCount to something more than 0, I have to set FixedRows back to zero again. I don't see the logic in that...

Thanks,

Paul.

Ah, sorry, I completely misunderstood your problem. I guess the code is missing some check(s) for "csDesigning in ComponentState"... But actually, I can't quite follow the logic in the code:

...
OldCount:=RowCount;
    if (OldValue=0)and(NewValue>=0) then begin
      FTopLeft.X:=FFixedCols;
      if RowCount=0 then begin
        if Columns.Enabled then
          FFixedRows := 1
        else
          FFixedRows := 0;
        FTopLeft.Y:=FFixedRows;
        //DebugLn('TCustomGrid.AdjustCount A ',DbgSName(Self),'
FTopLeft=',dbgs(FTopLeft));
        AddDel(FRows, 1);
        FGCache.AccumHeight.Count:=1;
      end;
    end;
^^^

-Fl?vio

--- El vie 5-feb-10, Fl?vio Etrusco escribi?:

your problem. I guess the code is missing some check(s) for "csDesigning in ComponentState"...

I don't understand, exactly where is it missing?

The logic is: given a empty grid and if developer adds at least one column then adds also a row so the column can be actually seen in grid for the rest, see my final note. But the question might yet be, why this code handling column count changes occur when adding rows to an empty grid?, the answer is that adding rows without columns do not make sense, you have to have at least one column so you see the rows :).

In the above logic there is a complement: it was assumed that if there were custom columns and grid was empty and because at least a row will be added automaticaly, the developer expects to see a column title, this part of the logic is not always true as you have found :), it's fixed in r 23650.

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/