Editing form with DataGridView causes many unwanted changes

[paul1956]

Environment

All

.NET version

.Net 9.0

Did this work in a previous version of Visual Studio and/or previous .NET release?

Framework.

Issue description

The WinForm designer for DataGridView adds additional row and column styles with every edit of the form (even if DGV is untouched) and creates new DataGridViewStyles with every edit. After first edit they are numbered 1 to N, next edit N to 2N, next edit 1 to N again if you don’t add any new styles. If you do the numbering gets more mixed up. The file size grows rapidly and it’s difficult to use Git difference because there are so many changes that need to be deleted.

Steps to reproduce

Create a for with DataGridView and anything else, edit anything and save. Upload to GitHub, edit anything, except DGV and save. Do diff and you will see many changes. Edit anything and you will see fewer diffs against GitHub. Each edit/save will cause unwanted changes.

Diagnostics

[merriemcgaw]

@Olina-Zhang can you repro for us. Please let us know if/when this regressed and whether it is VB only or also C#
@KlausLoeffelmann this looks like something up your alley.

[kirsan31]

whether it is VB only or also C#

It's c# also. But I'am not shure that it's happening on every edit.

[paul1956]

Every save, you can change multiple items but as soon as you save it happens. If you undo the edit and then save again more things change. So undo does not really undo.

[Olina-Zhang]

@Olina-Zhang can you repro for us. Please let us know if/when this regressed and whether it is VB only or also C#

Yes, we can repro it in .NET versions for C# and VB, and also repro in .NET framework 4.8.1.

When DataGridView has some additional row or column styles setting, upload app to github, then modify form, can see some extra DataGridView code change.

Here is just Form resizing:

[paul1956]

This happens even if you don't touch the DGV or Form. If you have a Label (Label1) on the Form and edit Label1.Text and save it happens.

There are 2 different issues the name changes in the Style variables in addition to the styles added to the rows and columns.

[paul1956]

@merriemcgaw @Olina-Zhang It also happens with TableLayoutPanel again to do with Style.

[merriemcgaw]

@Olina-Zhang would you be so kind as to add this to the designer repo, and I'll assign @KlausLoeffelmann

Given that this is also the case in .NET Framework, it won't be high on the priority list.

[paul1956]

@merriemcgaw this is the cause of subtle bugs, if the application adds row or column styles to ANYTHING, those styles are added at the end, the styles that are added by the bug come first, since these are visual they are harder for a developer to automatically test for and much harder to root cause.

It's unlikely that legacy .Net Framework projects are editing Forms, so they are not as affected. This bug mostly effects projects that are in active Form development, so I believe the normal priority criteria should not apply.

[merriemcgaw]

It's unlikely that legacy .NET Framework projects are editing Forms, so they are not as affected. This bug mostly effects projects that are in active Form development, so I believe the normal priority criteria should not apply.

@paul1956 that's a persuasive point, but changes to this component would introduce the risk of regression for those Framework projects that do get some design tweaks. There is still shared code between the two designers, and this is one of those spots.

[paul1956]

@merriemcgaw since there is no way to know how many times a file is edited, there is no way to depend on the old behavior. If an application has somehow worked around this issue (possibly by deleting all the extra styles at runtime) then fixing it would not be breaking, since only required styles would be there. In the current code Style.Count is correct no matter how many times file is edited.

[kirsan31]

styles added to the rows and columns.

@paul1956 are you talking about this: #8593
?