An old problem has suddenly reared its ugly head again. Why would some controls move on the form design surface at compile time?
Below are two views of a portion of a Windows Form. The left image shows the controls once I’ve moved them to where I want them. Notice that the combo boxes are horizontally aligned with the numeric up downs, and that the “Inches” label is nicely spaced between the border of the panel and the numeric up downs.
Then I hit F5 to compile and run the app. AS SOON AS it is finished compiling and the splash screen appears, the controls on the design surface in the VS IDE move. Notice in the right image how the combo boxes and Inches labels have moved down three pixels. Notice too that the numeric up downs aren’t moving. This behavior occurs whether or not I have locked the controls on the forms. And it happens every time I run from the IDE.
It gets worse and weirder. The combo boxes and numeric up downs continue to migrate downward three pixels three more times each time I hit F5 and then immediately quit the app. So after running the app a total of four times, the controls look like this:
Then it stops! No matter how many times I hit F5, the controls stay in the same position shown in the last image above.
I’m not running any resizing code at all; everything is done through the Anchor properties of the various controls. This happens to be on an inherited user control, but I’ve seen the behaviour on a regular form as well.
Nothing I do helps the problem, and none of the lists I post it to have a solution. So I grudgingly break out one of my technical support incidents from MSDN Universal, which hooks me up with May Ji, a support rep at Microsoft. To make a long story long, May tenaciously works on the problem, getting my code and duplicating my environment. Fortunately, although this is a fairly complex application that accesses databases and other resources, the problem is rearing its ugly head at compile time. That means she just needs all the referenced DLLs so she can compile; she doesn’t need to run it.
The problem didn’t appear on the first machine she tried it on, but she was finally able, after much dogged determination on her part, to reproduce the problem on another machine. After a lot more work trying to figure out what was wrong, and to get the WinForms team involved, she came up with two similar work arounds:
- Set the Anchor property for the moving controls back to the default Top, Left. Put code in the Form’s Load event to put the controls back where they belong. This means writing code that looks like this, for each control that is moving:
Me.cboInsulatingSheathing.Anchor = _
CType(((System.Windows.Forms.AnchorStyles.Top Or System.Windows.Forms.AnchorStyles.Left) _
Or System.Windows.Forms.AnchorStyles.Right), System.Windows.Forms.AnchorStyles)
- Move the equivalent code to set the Anchor from the WinForms designer-generated code to the Load event. All this option really does is save me from typing long, nasty lines of code, but I still have to hunt down and move the code for each control. And there are actually eight controls on this user control that move. I have literally hundreds of controls on forms and user controls throughout the application.
Bleech. What’s really disturbing is that the controls move even if I don’t have the form or user control open in the WinForms designer when I compile. Which means that any or all of those controls could be moving. (Well, apparently only controls that don’t have the default Top, Left set are at risk, but in this app that’s a lot of them.) So every time I compile, or at least every time I send an update, I have to check dozens of forms and user controls, looking within each tab, to see if anything has moved. I supposed I can set up an automated way of doing this, such as through source control, but I haven’t gotten that far yet.
That’s all that May could do. The only right way to fix this is for the WinForms team to develop a fix. But they’re in the final push for Whidbey as well as already working on Orcas. VS 2003 is old stuff now, and not a priority, even though it is the currently shipping version of Microsoft’s permier development tool. Aargh.
Oh well, at least I can hope that this blog post will save someone else the grief I’ve gone through on this.