Click here to Skip to main content
15,071,729 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hello,

I have created a application in the WPF in which I have a form for add/edit customer information. When in add mode window opens, it shows a blank textbox and in edit mode textbox will contain information from database.


I am using binding functionality like below.
XML
<Grid x:Name="MainGrid" DataContext="{Binding CurrentCustomer,Mode=TwoWay}" >
	<TextBox x:Name="txtCustomerName" Text="{Binding CustomerName,UpdateSourceTrigger=PropertyChanged,ValidatesOnDataErrors=True}"></TextBox>
	<TextBox x:Name="txtCustomerAddress" Text="{Binding Address,UpdateSourceTrigger=PropertyChanged,ValidatesOnDataErrors=True}"></TextBox>
</Grid>

Here CurrentCustomer is the object of the property class Customer

Following is one sample of the Customer class
C#
public class Customer 
{

	private string customerName;
	public string CustomerName
	{
		get 
		{
			return this.customerName; 
		}

		set 
		{
			this.customerName = value;
			this.OnPropertyChanged("CustomerName");
		}
	}
}

So now my question is will it leak any memory if I bind the text propery of text box like above?

According below link it may leak the memory if use data binding.
Link

WPF is something new for me and do not understand the concern with memory leak in this situation, so can anybody help me on this will it leak memory in above case?

and is there any easy way to check this code leaking memory or not?

Please help me to sort out this.

Thanks in advance.
Posted
Updated 25-Apr-13 4:51am
v5
Comments
Sergey Alexandrovich Kryukov 24-Apr-13 13:14pm
   
Did you apply the workaround recommended by this article. How did you managed to detect a memory leak? If you did it using Task Manager, you should not trust it.
—SA

1 solution

Please see my comment. Detecting a leak is not easy, and even understanding what a leak is is not so simple when it comes to managed memory. Please see my past answers explaining managed and unmanaged memory leaks:
Garbage collectotion takes care of all the memory management[^],
deferring varirable inside the loop can cuase memory leak?[^],
Best way to get rid of a public static List Causing an Out of Memory[^],
Memory management in MDI forms[^].

We don't really know what kind of memory leak you have, and, frankly, I don't sure if you have a leak at all or not. The actual detection of the leak is no so simple, and you should not trust not only Task Manager, but even the Performance Counter. Chances are, you would need a memory debugger. Please see the article and the list of the memory debuggers:
http://en.wikipedia.org/wiki/Memory_debugger[^].

Please see this Microsoft article on debugging, including memory issues: http://msdn.microsoft.com/en-us/library/ee817660.aspx[^].

Please see also this CodeProject article: Get Started: Debugging Memory Related Issues in .Net Application Using WinDBG and SOS[^].

[EDIT]

In WPF windows and controls, there is no a special need to use disposal at all.

Garbage collection copes with the managed memory by itself. You don't need to use GC class at all; and I recommend not touching it, ever (well, as a rule of thumb). Memory is reclaimed automatically. If is driven by making references unreachable. This is well explained here:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

As you cannot predict order of calling of your destructors, the destructors are also relatively rare in .NET programming.

And IDisposable.Dispose is still useful, but you can use it more with the using statement:
http://msdn.microsoft.com/en-us/library/yh598w02%28v=vs.80%29.aspx[^].

For an interesting example, please see my articles:
Using "using" Statements: DisposalAccumulator[^],
Hourglass Mouse Cursor Always Changes Back to its Original Image. How?[^].

It's good to implement RAII: http://en.wikipedia.org/wiki/RAII[^].

Please see this alternative: Hourglass Mouse Cursor Always Changes Back to its Original Image. How?[^].

—SA
   
v4
Comments
npdev13 25-Apr-13 1:53am
   
Thanks for excellent explanation and helpful links.

Yes you are correct I am not sure my code will leak memory or not because task manager does not make much difference.

I just want to add few thing related to my question is that, I also implment the IDisposable interface like below

public class PopupWindow : Window, INotifyPropertyChanged, IDisposable // This is custom popup window I have created.

In this class in the Dispose method have following code.

public void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}

so I think I not need to worry about the memory leak in this case right? it will automatically release memory as soon as this Dispose method call, right ?


Thanks,
   
I don't understand why do you suppress finalization. I saw this technique in other places, but I don't understand why would you do it in this case. It is used to substitute cleaning by destructors with cleaning by IDisposable.Dispose. Look at the help page of GC.SuppressFinalize, to understand the technique using it.

Dispose(bool) is something used with Forms, but not with WPF (note that Dispose(bool) is unrelated to IDisposable.Dispose, it is used to create a dispose chain).

As to WPF Window and all its base classes, IDisposable is not used at all. One of the uses of IDisposable is cleaning of unmanaged resources. They are used in Forms, but not in WPF. More generally, if you only work with managed memory, you can leave without disposing mechanism at all. Use use only garbage collection. How? By never using GC class...

—SA
npdev13 25-Apr-13 10:33am
   
so you mean we no need to use disposing mechanism for the WPF window? Will it release automatically resource when close the window?

and what you mean by last sentence "use only garbage collection. by never using GC class".
can you please give idea by which way should use garbage collection then ?

Thanks in advance.
Sergey Alexandrovich Kryukov 25-Apr-13 10:44am
   
No need, generally. Yes, it will.

Last sentence? I'll explain by updating the answer. Please see, after [EDIT], in a minute or two...
—SA
Sergey Alexandrovich Kryukov 25-Apr-13 10:54am
   
Done. Please see after [EDIT].
—SA
npdev13 25-Apr-13 11:04am
   
Ok thanks, +5 for answer.
Sergey Alexandrovich Kryukov 25-Apr-13 11:11am
   
If you basically got the answers, please accept it formally (green button).
But if you have further questions on the topic, of course you are welcome to ask.
—SA
npdev13 26-Apr-13 0:35am
   
I have still one thing that confusing me is that if it is not require any disposing mechanism for WPF window and when we close window it will release the memory. but in my application why memory going increase in task manager when I just open and close popup window (in this popup window I am loading usercontrol) repeatably, so when ever I do that open-close popup window operation some memory keep allocated.

for example : when first time open : 60000 KB
after open - close window 10 time : around 65000 KB
again after open-close windwo 10 time : around 68000 KB

so this way it increase little memory in task manager. so can you please help me on this what exactly casuing the issue.

I can give some code snippet if you require it how I did code.

I will appreciate if you give me hint to sort out this issue.


Thanks,
   
Task manager is not really indicative of memory leaks, unless the memory usage grow is really big and consistent. The memory allocation is driven by your code, reclaiming of memory is not. GC "decides" on some convenient moment to reclaim memory; it will try to consolidate more of memory, to reclaim more at once, hence reducing the total number of operations. You have little control over it, even if you us GC.Collect or something like that. You can experimentally see that this is just the recommendation, to GC which it does not have to follow.
—SA
npdev13 26-Apr-13 3:09am
   
so it will not create major problem even if I use GC.Collect or not, as memory reclaim is not handle by code.

Thanks for your support.
Sergey Alexandrovich Kryukov 26-Apr-13 10:00am
   
You are very welcome.
Good luck, call again.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900