How to make gap between lines in StringGrid

[shobits1]

How do I restrict the number rows and columns.

Just call NewWorkbook and pass the requested column and row counts as parameters. Note that this is for visual and navigation purposes only...

Just what I want 

Unfortunately I still cannot reproduce the crash you observe. But anyway, the code at line 4454 really is very fragile. I think it is working now. Please test.

For Now it works just fine

The row heights and column widths are lost because my sample code only modified the grid values, but not those in the underlying worksheet. I'll fix it in the next update.

UpdateRowHeights cannot be removed because of some special cases which I cannot remember... (maybe vertically merged cells)

The problem still persist; when scrolling row heights changes.
+what I proposed was delete just that one line in the TopLeftChanged procedure,, I tried it and it works with no apparent problem so far.

[wp]

The row height / col width issue should be fixed now. You can also use DefaultRowHeight and DefaultColWidth.

[shobits1]

thank you, it works. 

DefaultColWidth not working.

good night.

[wp]

It is working here... Can you post the code in which DefaultColWidth is not working?

[EDIT] And what is not working?

[shobits1]

maybe I wasn't clear, supposedly I configure DefColWidth to 20px I will get the attached image 1 (designtime) but when I run the application I get image 2 (runtime).

you see the initial state of the Grid when running the application doesn't reflect the property entered; the default column width will only work for newly created cell (beyond AA101), a work around is to empty the grid then all new cell will have DefColWidth value.


EDIT: this not big deal for me since I'll call NewWorkbook(0,0) first; but for others It may be a problem.

[wp]

Ah, I forget about designtime. Should work now (let's hope that there are no regressions...)

[shobits1]

Ah, I forget about designtime. Should work now (let's hope that there are no regressions...)

seems all good,  .

Now: I'm struggling with merge cells and borders, I keep getting some kind of glitch (maybe I'm doing it wrong); could you please post a sample code to merge cells 3cols by 3row (A1:C3) with borders.

[wp]

Try this:

Code: Pascal  [Select][+][-]

1. Grid.MergeCells(Rect(1, 1, 3, 3));  // A1:C3
2. Grid.Cells[1, 1] := 'These cells are merged';
3. Grid.CellBorders[Rect(1,1, 3,3)] := [cbNorth, cbSouth, cbEast, cbWest];  

It is not absolutely correct because in my opinion the merged block should get its format from that of the upper left corner, i.e. Grid.CellBorder(1,1) := [...] should be sufficient, but this obviously does not work -- I'll have to dig into that.

[shobits1]

The attached image is what I get, the same problem I'm having - the cells don't merge correctly and borders is just wrong.

BTW, my application uses bdRightToLeft ( sorry I didn't test with bdLeftToRight before posting which obviously works).

[wp]

Oh - I did not care about Right-to-Left in fpspreadsheet because I don't live in that culture, and it certainly won't be soon that this is working correctly...

I just uploaded a new version in which the properties of the grid affecting a range of cells have individual coordinate parameters now, instead of a single Rect, which appears to be more consistent with the other properties. Unfortunately this will break existing code: Instead of

Code: Pascal  [Select][+][-]

1. Grid.BackgroundColors[Rect(1,1, 3,1)] := clYellow;

use

Code: Pascal  [Select][+][-]

1. Grid.BackgroundColors[1,1,3,1] := clYellow;

now. - Unfortunately, properties cannot be "overloaded" - or can they?

There is also a new method ShowCellBorders() for easier application of cell border lines to a range of blocks - please see the wiki at the bottom of chapter http://wiki.lazarus.freepascal.org/TsWorksheetGrid#Cell_formatting

And finally I should mention that the sample project fpsgrid in folder "examples\visual\fpsgrid_no_install" contains some more examples of how to apply the TsWorksheetGrid in a TStringGrid-like manner.

[wp]

Just because you had an issue with ColCount and RowCount before: These properties are working now as well. They still default to 26x100 data cells, but can be changed at designtime, it is no longer required to call NewWorkbook. Still the grid expands if a cell is added beyond these limits or if a data file is read - I'm not 100% sure if this is a desirable feature in every case, maybe there's a need for a new property "AutoExpand". What's your opinion?

[shobits1]

Oh - I did not care about Right-to-Left in fpspreadsheet because I don't live in that culture, and it certainly won't be soon that this is working correctly...

Thank you for your great help; I'll try to make it for me - could you give me some guide lines.

Just because you had an issue with ColCount and RowCount before: These properties are working now as well. They still default to 26x100 data cells, but can be changed at designtime, it is no longer required to call NewWorkbook. Still the grid expands if a cell is added beyond these limits or if a data file is read - I'm not 100% sure if this is a desirable feature in every case, maybe there's a need for a new property "AutoExpand". What's your opinion?

it fits exactly what I need, but for others I don't know. still an 'AutoExpand' or 'FixedSize' would be appreciated by the community (I think).

[wp]

Oh - I did not care about Right-to-Left in fpspreadsheet because I don't live in that culture, and it certainly won't be soon that this is working correctly...

Thank you for your great help; I'll try to make it for me - could you give me some guide lines.

Oooh - that's not easy, it goes into the heart of many routines. Currently I am assuming that column, pixel or character indexes increase from left to right, in RTL they increase from right to left, i.e. the standard loops "for index := left to right" are passed only once. The most difficult part will be the drawing routines (DrawXXXX) with the complicated special cases of merged cells, cell text overflow, or rich text formatting. The TCustomGrid has protected methods BiDiFlipX etc which can be used to flip x coordinates and column indexes. To be honest I could not even tell what might be easiest to get started, maybe the border thing that you mentioned - seek for "Border", try to understand what is going on and decide whether the drawing, counting or whatever direction must be reversed. Try to go in little self-contained steps. Whenever each of these steps is working create a diff file and post it here, I will have a look at it because not everything in the sources is well-commented and self-explaining, and you may destroy things.

Is Right-to-left you native reading direction?

[shobits1]

Oooh - that's not easy, it goes into the heart of many routines. Currently I am assuming that column, pixel or character indexes increase from left to right, in RTL they increase from right to left, i.e. the standard loops "for index := left to right" are passed only once. The most difficult part will be the drawing routines (DrawXXXX) with the complicated special cases of merged cells, cell text overflow, or rich text formatting. The TCustomGrid has protected methods BiDiFlipX etc which can be used to flip x coordinates and column indexes. To be honest I could not even tell what might be easiest to get started, maybe the border thing that you mentioned - seek for "Border", try to understand what is going on and decide whether the drawing, counting or whatever direction must be reversed. Try to go in little self-contained steps. Whenever each of these steps is working create a diff file and post it here, I will have a look at it because not everything in the sources is well-commented and self-explaining, and you may destroy things.

Is Right-to-left you native reading direction?

I'm not expecting anything easy right now, but I could always try and learn things on the way (that how I self-learned many programming languages). I have a hunch that the problem lays in merge cells routine so I will start there.

yes my native language is RTL; and even though I could use English this application is preferred  to be in native tongue.

[shobits1]

So far I managed to correct the apparent problems but I face new one  ; the Arabic text is drawn in reverse although other component (like button) works perfectly -see attached image- ; any idea how to fix this.

Also a diff file is attached, could you review the changes.