Today I dealt with a bug that had an unexpected but simple fix. Those always seem to be the kind of bugs that can easily take up a lot of time and this one was no exception.
I have a Win Forms UserControl to present a list of items, lets call it the SelectContentControl. The SelectContentControl is not a general purpose control because it shows a list of very domain specific items. Up to this point it was only used in once place on a different form. However I was working on adding a new form to the application and reusing the control.
The SelectContentControl contains a header, which is itself a separate UserControl, and a scrollable panel that contains multiple instances of a ItemControl class. ItemControl is a UserControl that does some custom painting on itself and contains a number of standard controls like checkboxes and labels.
The problem was with ItemControl. Some parts of the control did not resize properly and were either clipped or not showing at all. Yet I could launch the other form and see the same control working without any problems.
First I compared the two forms paying close attention to how the control was used in the form. Both forms seemed identical and the code itself was minimal. In fact both forms used only a single line of code to connect the SelectContentControl to the data source and a couple other lines to set a property according to user preferences. Very little code.
Next I thought this could be a resizing problem. I went through every control in SelectContentControl starting at the top and confirmed that all the anchoring and docking properties were correct. I expected them to be correct because the control works beautifully on one form but not the other. After all this was not new code: this control was used in software already shipping to customers without any known problems.
Frustrated with it at this point I went to lunch.
After lunch I added some Resize event handlers to the SelectContentControl and the ItemControl. “I shouldn't have to do this” I thought to myself because all the anchoring and docking properties would do the resizing for me. But still I thought maybe I could learn something by logging the resize messages and comparing the behavior on the good form to the broken form.
I noticed that on the good form the Resize event is being fired only one time when a ItemControl is created. Specifically its being called on line #4 below where I set the initial size of the control. This code shows the body of the loop used to add items to control for display.
1: ItemControl c = new ItemControl();
2: c.Location = loc;
3: c.Anchor = AnchorStyles.Left | AnchorStyles.Top | AnchorStyles.Right;
4: c.Size = new Size(itemsPanel.Size.Width, c.Size.Height);
5: itemsPanel.Controls.Add(c)
The bad form is firing the Resize event four times! Its being called once on line #4 like the good form and three more times on line #5 where the new ItemControl is added to the scrollable panel container. Finally I feel like I'm getting somewhere. Because I can step into the .NET framework source code I get a good stack trace and I can peer inside the forms and see what’s happening under the hood. Studying the stack trace I see that the multiple resize events seem to be a result of changing the font on the ItemControl.
The font? Yes the font. It turns out the good form has the default font value "Microsoft Sans Serif, 8.25pt" but I had changed the font on my new form to "Calibri 9pt". I changed the font on my new form back to the default and everything resized properly and looks exactly as it should. Why the font caused this problem I believe has something to do with automatic scaling in Windows forms but I have to leave those details for another time.
Subscribe