I've noticed that I have this huge memory leak.My app relies heavily on infragistics ui components, and our code createsAnd destroys many UserControls that comprise mostly of UltraTextEditors.After some research I found that the constructor is not called on ANY control that contains an UltraTextEditor (and probably other editors as well).
This seemed so weird to me that I started a new project, that contains a main form, and a single user control, which in turn contains a single UltraTextEditor. I added a destructor to this control, and set it to print a message to the debug console.To the main control I added a single button that creates my user control and looses reference to it, and then a call to GC.Collect();.
If the control contains the UltraTextEditor, the descructor is never called, if I remove the line with "this.controls.add(ultraTextEditor1); " the destructor is called as expected.Why does this happen? Is there some setting I need to know of somewhere that prevents my control from being GCed? Does the UltraTextEditor save a reference to the parent class in some static place that never gets out of scope?
What is the status of this issue? Is there any workaround for this issue? Is there an interface we can get at to manually unhook the static event handlers holding the controls in memory when the control is disposed of? This issue is causing us a lot of pain.
I am running into this issue as well. I am using 2008.3 with the latest hotfix. Is this schedule to be fixed soon?
Very well, will do.
Thanks.
-Yossi.
You could have developer support submit a bug regarding this issue, but I can't say whether or not it will be implemented as such.
-Matt
Well, Destructor cannot be inherited or overriden , but they are always called regardless of what inheriting classes do. but you dont have to re-implement it accross the inheritance graph.
http://msdn.microsoft.com/en-us/library/66x5fx1b(VS.80).aspx
the link above has an example and the output that demonstrates this. (C:B,B:A all have destructors, and all destructors are called)
The fact that Control always calls Dispose when it is GCed also demonstrates this fact (if you implement a UserControl and override the Dispose method, you will see that it gets called when the object is out of scope and GCed, even if you dont explicitly call it in your own destructor).
Therefore this issue's impact to your development effort would be zero, since as far as i recall, all your controls already inherit from Control, and thus the call to Dispose will be made if you use WeakEvents and allow objects to be garbage collected.
My porblem is that if this bug remains in your infrastructure then it forces the users to effectively treat your objects as unmanaged, and is almost exacly like calling "delete" for every "new" object in c++. this considerably increases the chances for memory leaks and lost objects for the users of the package, since C# developer relay on the managed framework to handle garbage collection.
Is there any chance this issue will be fixed?
-Yossi