Windows Forms BindingSource only prevents object leaks for first level of nested property binding - by Nicole Calinoiu

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


2
0
Sign in
to vote
ID 607381 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/30/2010 11:00:57 AM
Access Restriction Public

Description

One of the main purposes of the BindingSource component is to avoid object leaks that occur when binding directly to data objects.  This 

seems to work fine when binding to a second-level nested property, but object leaks re-appear when binding to a third-level nested 

property when all objects in the chain implement INotifyPropertyChanged.

For example, consider the following Thing implementation:


public class Thing : INotifyPropertyChanged
{
	public Thing()
	{
	}

	public event PropertyChangedEventHandler PropertyChanged;

	private string _name;
	public string Name
	{
		get
		{
			return this._name;
		}

		set
		{
			if (this._name != value)
			{
				this._name = value;
				this.FirePropertyChanged("Name");
			}
		}
	}

	private Thing _child;
	public Thing Child
	{
		get
		{
			return this._child;
		}

		set
		{
			if (this._child != value)
			{
				this._child = value;
				this.FirePropertyChanged("Child");
			}
		}
	}

	private void FirePropertyChanged(string propertyName)
	{
		var handler = this.PropertyChanged;
		if (handler != null)
		{
			handler.Invoke(this, new PropertyChangedEventArgs(propertyName));
		}
	}
}

If one binds directly to the Name property of a Thing instance, there is no object leak.  However, an object leak is introduced if one binds directly to the Child.Name property of a Thing instance unless one uses an intermediary BindingSource.  However, even when binding via a BindingSource whose DataSource is the root Thing object, an object leak results if one binds to the Child.Child.Name property.

The above behaviour can be observed in both .NET 3.5 SP1 and .NET 4.0.
Sign in to post a comment.
Posted by Microsoft on 10/20/2010 at 11:27 PM
Thank you for reporting this issue. Customer feedback is a critical part of a successful, impactful software product. Unfortunately another part is the reality of schedules and the need to prioritize investments according to the objectives of the product. We have evaluated the issue that you have reported and at this point in the product's lifecycle, it does not meet the criteria to be addressed. This evaluation is carefully done and considers many aspects including the cost of the fix, implications of the change, and the number of reported instances of the issue.

Many customers have found it useful to discuss issues like this in the forums (http://www.microsoft.com/communities/forums/default.mspx) where Microsoft and other members of the community can recommend ways of achieving the behavior you are interested in.

Thank you,
The Windows Forms Product Team

Posted by Nicole Calinoiu on 10/1/2010 at 6:19 AM
I have attached a demo project (VS 2008 since the .NET 3.5 SP1 problem is my own immediate priority) and profiler screenshots. The procedure used to capture the profiler screenshots is described in the ReadMe.txt file in the ProfilerScreenshots folder in the zip archive.

Incidentally, the BindingSource itself leaks due to the same failure to clean up the valueChangedHandlers registrations created by the RelatedPropertyManager.

For now, I'm planning on trying to address this problem in my own work by creating a BindingSource subclass that, as a last step during disposition, cleans up valueChangedHandlers targeting a RelatedPropertyManager whose root parentManager's DataSource is the BindingSource instance. This is a nasty, nasty hack, but TypeDecriptor.Refresh doesn't clean up the ReflectTypeDescriptionProvider._propertyCache registrations, and I can't seem to find any extension point(s) that would allow me to change the related property management without replacing very large chunks of the binding infrastructure. If you could suggest any cleaner workaround that might be implemented against shipping .NET versions, that would be much appreciated.
Posted by Microsoft on 10/1/2010 at 12:30 AM
Thank you for reporting this issue.
Could you please attach a demo project and screenshots to help us reproduce this issue?
Posted by Microsoft on 9/30/2010 at 6:06 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)