View Issue Details

IDProjectCategoryView StatusLast Update
0031766LazarusLCLpublic2017-05-24 21:22
ReporterAlexander Koblov Assigned ToOndrej Pokorny  
Status resolvedResolutionfixed 
Product Version1.9 (SVN) 
Summary0031766: Grids: Cannot set LeftCol
DescriptionCannot change LeftCol in TDrawGrid/TStringGrid.

Works fine in Lazarus 1.6.4.

Details below.
Steps To ReproduceCompile attached project in Lazarus 1.6.4. Execute and press button. First column will become 5.

Repeat with Lazarus 1.8/1.9. First column will become 1.

I found that it is broken by commit 52322.
TagsNo tags attached.
Fixed in Revision54841, 54970
Attached Files


Alexander Koblov

2017-05-08 12:49

reporter (128,609 bytes)

Zeljan Rikalo

2017-05-08 21:08

developer   ~0100163

Assigned to Ondrej since he is commiter of r52322, this is regression.

Ondrej Pokorny

2017-05-08 23:26

developer   ~0100169

Last edited: 2017-05-08 23:27

View 2 revisions

This is wanted behavior. You cannot scroll past column 1!

Add more columns and/or resize the grid so that it's possible to scroll to column 5.

The behavior you want to have was a bug before r52322.

+ since r54841 the relative offset is also taken into account. But it will never scroll to column 5.

Jesus Reyes

2017-05-18 09:27

developer   ~0100387

Last edited: 2017-05-18 09:28

View 2 revisions

In delphi you can, so you broken delphi compatibility here. (well, at least Turbo delphi, does. I don't know what it does in more recent versions)

Ondrej Pokorny

2017-05-18 10:16

developer   ~0100391

> In delphi you can, so you broken delphi compatibility here.


What we need is the ScrollPastLastCol and ScrollPastLastRow options, that would enable scrolling past the last column and row. Just how it is done in e.g. TSynEdit.

Patches are welcome!

Ondrej Pokorny

2017-05-18 15:57

developer   ~0100440

> Patches are welcome!

Nevermind. I added goScrollToLastCol, goScrollToLastRow in r54970. Alexander, enable goScrollToLastCol and you will be able to scroll to column 5 both in code and with mouse.

And no, I won't do it in Delphi-compatible way. Because the Delphi behavior is a bug. Try to click on the scrollbar with mouse after you set LeftCol out of the scrolling bounds - the grid jumps back instantly.

I hope you don't want to keep the LCL in the state of 20 year old components ;)

Jesus Reyes

2017-05-18 17:39

developer   ~0100445

Last edited: 2017-05-18 17:48

View 2 revisions

Sorry, I disagree.

In fact, delphi compatibility is not very high in my list (or the grid will had become a functional clone of the delphi one), it is more important auto compatibility. I will always prefer remain compatible with previous versions and add options for when compatibility present a functional problem. In other words, if you find what you think is a bug, fix it, but fix it in a way that keep (by default) the previous behaviour if that behaviour is useful or necesary for keeping previous funcitionality and not the other way around which is "if you want compatibility with previous versions, change some options. Everybody hates modifying working code!

After all what you think is a bug may be a feature. In your example, there may not always be a scrollbar for clicking and so your perceived problem is none and so it is also the bug. BUT if for some reason the programmer want to show only (or initially) columns starting on LeftCol (s)he could do it, after all, that is a reasoned decision because LeftCol must be changed on code, that should not be considered a bug.

Forgot: Please arrange things, so the previous behaviour is kept by default and new the behaviour should be activated with the new options. Please document it.

Ondrej Pokorny

2017-05-18 17:51

developer   ~0100446

> Forgot: Please arrange things, so the previous behaviour is kept by default and new the behaviour should be activated with the new options.

The old behavior cannot be achieved with any current option.

Jesus Reyes

2017-05-19 14:14

developer   ~0100492

If the old behaviour cannot be restored with the new properties, I don't see the case on adding them, what are they for then?

Ondrej Pokorny

2017-05-19 21:33

developer   ~0100509

> If the old behaviour cannot be restored with the new properties, I don't see the case on adding them, what are they for then?

To be absolutely honest - to make you happy.


Jesus, I really don't get your complaints. Should I create an option for every bug I fix for backwards compatibility with the old buggy behavior? Do you really take advantage of this "feature"? To me it looks like you are just making up a theoretical problem.

In Delphi after you set LeftCol out of the scroll bounds:
1.) It scrolls back instantly when you click on the scrollbar.
2.) It scrolls back instantly when you move the selection to any other cell - even ones that are visible and even if the scrollbars are hidden.

+ You are even allowed to scroll completely out of the grid with:
  StringGrid1.LeftCol := StringGrid1.ColCount*2;

A very useful feature, indeed.

I really don't get it.


You are welcome to check goScrollToLastCol for yourself. You should be able to see the differences.

Jesus Reyes

2017-05-22 06:17

developer   ~0100573

> To be absolutely honest - to make you happy.

Thanks, but that is not necessary, don't over complicate things. If you have to add options, add them because they are really needed (we can debate if options old or new are needed in some other place if you want), if the added options don't help in anything, don't add them. In this case, again, if the options don't restore the old behavior, don't add them, if they are already added, remove them.

> To me it looks like you are just making up a theoretical problem.

Lets see, before, you could set leftcol to some value and the grid would react by making the the first non-fixed column to be the first. IF that depicted behavior could still be achieved in the current grid, then, yes we (ie. Alexander Koblov and me) are making up a theoretical problem, I'm sorry, close this theoretical bug report and be done with it. If not, then the problem exists and is not a theoretical one.

Please don't make theories about me and Delphi issues, yes I cited the compatibility issues and then I said I don't care, I'm afraid both are a shiny true.

If Delphi has issues in his implementation that I don't know then bad luck, I can tell you this: I think I understand what leftcol does and that was enough for implementing or accepting that feature, I most certainly never did a test program in Delphi for testing this feature, let alone for finding Delphi issues, if really Delphi has issues here, I DON'T CARE, if Lazarus had issues here, I DO CARE, we should have fix them instead of removing features we don't understand or like.

Here I have to say that, TBH sorry, I don't remember if *I* specifically implemented that feature, some investigation should be performed but I let that to the interested party, but anyway, I still take responsibility for it.

Ondrej Pokorny

2017-05-24 21:22

developer   ~0100657

I defined Delphi and LCL 1.6 behavior as bug: it is wrong if code forces the scrolling position out of scrolling bounds and then automatically forces a jump back on mouse click or key press.

I added goScrollToLastCol options which extends the scrolling area to max column so you can scroll to any LeftCol (until ColCount) with both code AND MOUSE. The Delphi and LCL 1.6 incompatible part is the scroll with MOUSE.

If I enable it by default, other people will shout instantly that they don't want to scroll with mouse until ColCount-1 because Delphi and LCL 1.6 doesn't do it.

Personally I don't know why goScrollToLastCol is useful - but this means nothing. I am used to implement LCL features that I don't need. goScrollToLastCol is there to allow you to do "LeftCol := ColCount-1" with correct scrolling. If I understand you correctly, you don't need the feature either.

Issue History

Date Modified Username Field Change
2017-05-08 12:49 Alexander Koblov New Issue
2017-05-08 12:49 Alexander Koblov File Added:
2017-05-08 21:08 Zeljan Rikalo LazTarget => -
2017-05-08 21:08 Zeljan Rikalo Note Added: 0100163
2017-05-08 21:08 Zeljan Rikalo Assigned To => Ondrej Pokorny
2017-05-08 21:08 Zeljan Rikalo Status new => assigned
2017-05-08 23:26 Ondrej Pokorny Fixed in Revision => 54841
2017-05-08 23:26 Ondrej Pokorny Note Added: 0100169
2017-05-08 23:26 Ondrej Pokorny Status assigned => resolved
2017-05-08 23:26 Ondrej Pokorny Resolution open => won't fix
2017-05-08 23:27 Ondrej Pokorny Note Edited: 0100169 View Revisions
2017-05-10 05:46 Alexander Koblov Status resolved => closed
2017-05-18 09:27 Jesus Reyes Note Added: 0100387
2017-05-18 09:27 Jesus Reyes Status closed => assigned
2017-05-18 09:27 Jesus Reyes Resolution won't fix => reopened
2017-05-18 09:28 Jesus Reyes Note Edited: 0100387 View Revisions
2017-05-18 10:16 Ondrej Pokorny Note Added: 0100391
2017-05-18 15:57 Ondrej Pokorny Fixed in Revision 54841 => 54841, 54970
2017-05-18 15:57 Ondrej Pokorny Note Added: 0100440
2017-05-18 15:57 Ondrej Pokorny Status assigned => resolved
2017-05-18 15:57 Ondrej Pokorny Resolution reopened => fixed
2017-05-18 17:39 Jesus Reyes Note Added: 0100445
2017-05-18 17:48 Jesus Reyes Note Edited: 0100445 View Revisions
2017-05-18 17:51 Ondrej Pokorny Note Added: 0100446
2017-05-19 14:14 Jesus Reyes Note Added: 0100492
2017-05-19 21:33 Ondrej Pokorny Note Added: 0100509
2017-05-22 06:17 Jesus Reyes Note Added: 0100573
2017-05-24 21:22 Ondrej Pokorny Note Added: 0100657