Question

In a WinForms application I have a number of instances where I add a control to a container in response to a user action (panel.Controls.Add(new CustomControl(...))), then later clear the panel (panel.Controls.Clear()) and reuse it.

In production, the app occasionally throws an exception relating to GDI errors or failing to load an ImageList. This usually happens on machines with limited resources and with users that use the application intensively over the day. It seems pretty obvious that I have a GDI handle leak and that I should be disposing the controls that get cleared from the container, however any explanations I can find are vague about where and when the control should be disposed.

Should I dispose the child controls immediately after clearing the container? Something like:

var controls = new List<Control>(_panel.Controls.Cast<Control>());
_panel.Controls.Clear();
foreach (var c in controls) c.Dispose();

Or should I track the controls in a list and call dispose in the container’s Dispose() method? Such as:

List<Control> _controlsToDispose = new List<Control>();
void ClearControls()
{
    _controlsToDispose.AddRange(_panel.Controls.Cast<Control>());
    _panel.Controls.Clear();
}
void Dispose()
{
    ...
    foreach (var c in _controlsToDispose) c.Dispose();
}

Answer 1

After (somewhat effectively) correcting any cases where my app wasn’t disposing cleared controls I can come up with some points:

• Sometimes I’ve pre-built a list of controls, stored for example in the Tag property of a collection of ListViewItems or TreeViewItems. They shouldn’t be disposed on clear, but the entire list should be iterated and ((Control)item.Tag).Dispose() called in the parent’s Dispose() method.
• If the control isn’t going to be used again, which can happen when I create it on the fly, it should be disposed when it is cleared from the container.
• When clearing and adding controls on the fly you need to consider the lifecycle of the controls to determine whether to dispose them immediately, defer it until the parent is being disposed, or to not worry about it.
• I had a situation where I removed a control to display a ‘Loading…’ message, then dropped the control back in later, in response to a thread completing. I added a call to dispose the control when I removed it, which caused errors when trying to add it again. Because of the threading issue it wasn’t straightforward to debug. The point is that the lifecycle can depend on threads other than the UI thread. The case in point was a matter of 20 seconds after the form was displayed, so at least the control still existed. Managing a situation where a control can be destroyed with threads still wanting to refer to it is probably a case for weak events.

I haven’t been able to find any best practices or recommendations on managing control lifecycle and disposal. I guess the rule is just that if a control doesn’t end it’s life nested on a control that is disposed, it has to be disposed manually, whenever it isn’t going to be used again, or in the parent control’s Dispose() method at the latest.