TStringGrid cell copy paste

[Чебурашка]

Hello,
I have a TStringGrid with some not empty text in a cell. If I select that cell, do CTRL+C, and then CTRL+V on a TEdit I get this:

The TEdit pasted text includes a white character at the end of the text.

If I change the TEdit with a TMemo I see that the white character is a newline.

From where this extra character come from? Can this be avoided with some config option?

[Чебурашка]

Update: in the attached zip a version of the project that sets programmatically the content of the cell [1,1], and where is clear what is the assigned text (not in lfm but in Creation).

[Bart]

Apparently this is by design?
See the code in procedure TCustomStringGrid.CopyCellRectToClipboard(const R: TRect); in the grids unit.

Notice that his happens (selected one cell, as in your case) if the editor is not active.
If you have the cell-editor active and then copy the contents, then no LineEnding is added.

You might add a feature request in the bugtracker to e.g. not add the LineEnding if the selection only contains a single cell?

[wp]

This is the same behaviour as in Delphi and in Excel (but not in Libreoffice Calc). But when the grid is editable and you double-click on the cell so that the entire cell text is highlighted, the text is copied without the added line-ending.

On the other hand, the grids have the Options2 which could be extended. What would be a good name for such an option? "goCopyWithoutTrailingLinebreak" (similar to the "soTrailingLinebreak" option of TStringList)? But - on the other hand again - Options2 is a property of TCustomGrid, and goCopyWithougTrailingLinebreak would be evaluated only in the descendant TCustomDrawGrid's descendant TCustomStringGrid which looks wrong to me.

[Чебурашка]

Thanks for the observations.
Being this process part of a more broad mechanism that must ensure the copy/paste of areas of the grid, current behaviour seems quite senseful.

I will trim on paste.

[Bart]

Yes, an option would be nice.
"goCopyWithoutTrailingLinebreak" is fine with me.
I don't think we should have new Options3/4/5/6/7 for every option we add that doesn't fit into it's top ancestor, so I would just add it to Options2 (which merely exist because you can only have 32 enums in a published set).

What about the suggestion to not adding the trailing linebreak if the selection is just a single cell?
IMO it makes no sense to add it in that case.

Bart

[Чебурашка]

Being this part of a broader feature (copy rect), modifying the behavior would create benefit in cases like mine, but issues/complexity to all others, for example because one client should be aware that NewLines is always there except when there is one row or for the last row where there are many, while currenlty logic is more simple and consistent.

I'd say that better keep things simple as they are now.

[wp]

What about the suggestion to not adding the trailing linebreak if the selection is just a single cell?
IMO it makes no sense to add it in that case.

Well, at least Delphi and Excel add it, for whatever reason (I agree that it does not make sense...). Therefore, a change should be keep the current behaviour by default.

[Bart]

Well in that case just make it dependant on then new option.
It's not a big deal IMO.

Bart

[wp]

I committed a new version to main in which the grids can set the new option goCopyWithoutTrailingLinebreak to avoid the trailing line breaks. Inner linebreaks in a multi-cell selection are not affected.

[Bart]

Nice.

Bart