Visual Studio WinForms bug

0
245

I’ve been working with WinForms for a very, very long time. Usually, because companies that hire me use this technology and I’m brave/resigned enough to help them in their strugglings 🙂 Visual Studio has quite good support for the WinForms, but it also suffers from a very serious bug(?) or shortage (at best) – when a new element is added to a form, sometimes it severely changes underlying code. On the surface, the form looks the same, but under the hood, a mess happened. It’s particularly severe when we work in a group and we want to commit our small change to the repository.

Code Review for this small change is almost impossible, as the number of changes made accidentally by the VS is enormous. Fortunately, Git is the tool that may help us to overcome this problem.

Let’s visualize what I mean. If we have a simple form and want to add another control to it (named checkbox1:)), the expected and desired output is:

Screen from SmartGit comparison pane. The green lines on the right are additions, and there are only a few of them – all relevant ones – starting from the bottom: definition of the checkbox, making it a child of the parent form, and setting properties block on the top. One line is not shown here, but is marked in green on the right scrollbar – it’s an instantiation of the checkbox. Why PerformLayout invocation has been added just now? Have no idea, Visual Studio surprises me often when working with WinForms.

The checkbox was added and only relevant lines are visible in the comparison tool. It means that VS did a good job and didn’t change anything unnecessary.

But, there might be a situation like this:

At first glance, it looks messy, but Visual Studio did no harm here. The controls are reordered, but their properties are untouched, and as before, only a few new lines related to checkbox1 were added. It’s not a perfect situation and I’d not recommend committing such a file to the repository.

The checkbox was added and the old controls have been reorganized. Their positions and other properties have been unchanged, so it’s not very severe, although it will cause problems during code review. Another slightly more severe case:

This is even worse – imagine you’re reviewing this code. Git clearly shows that some controls were added, and some were deleted. We again just added one checkbox.

Unfortunately, in the most complex forms, sometimes the output looks as messy as this one:

This form is a big one. The Visual Studio bug is clearly visible now. I added one checkbox, but all controls have been affected. Take a look at their positions. They’ve been changed – all of them.

The comparison tool shows hundreds of lines changed. Why, we only added one small checkbox, so at most 10 lines of code should be added, and zero changed. But we see that all controls have slightly changed positions and sizes – a complete disaster! The form still looks like before, but internally it’s been completely changed.

This is some kind of bug in Visual Studio and I haven’t found its proper resolution. Instead, I learned what to do if it occurs. Particularly, the Git feature called „hunks” can help us overcome it.

I described Git hunks in one of my previous notes. In short – it’s a feature that allows to stage only part of the file, not the whole one. And probably you already know how to use it in our case. We just need to stage the lines truly needed when we added/changed the control on the form, not all the lines changed by Visual Studio.

So:

  1. Add control (checkbox in our example) to the form, change its name – for example to chkbxOnAndOff
  2. Compare the file – before and after addition. Find the lines with the name chkbxOnAndOff. Stage them using Git hunks.
  3. Discard all other changes. Recompile, and see what it looks like. If the position is incorrect, move the control to the correct position on the form, remember the coordinates, discard all changes and write correct, remembered coordinates manually.
  4. Repeat the procedure for all the next controls you wish to add.

That’s it. When the above procedure is finished, you have a staged file ready to be committed. This is only a bypass for the VS problem I found, but as they say – beggars can’t be choosers, right? 🙂

0 0 votes
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments