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?
Just saw your answer. Sorry about that.
I'll try it out my self :)
Having the same issues!
I must admit, like Pat H, that I can not recommend Infragistics to any companies as long as they have this issue.
Pat, did it work on 2008.3 as well, or??
sanjeevsai,
What you've described is entirely different from what's been described earlier in this thread. The issue mentioned earlier in this thread is unique to our Windows Forms controls, and you're using our ASP.NET controls.
Developer Support is still investigating the issue you've reported in support case CAS-24425-CMDQQ1. This sounds like something that we might have fixed already, though it'll take some further testing to be certain that your issue is the same as the one I'm recalling.
Hi Matt,
What Yossin is saying, is absolutly correct that infragistics controls are not releasing memory. I am also facing the same problem. Matt, its not with UltraTextBox control only but
with every control. I am using UltraWebGrid control and the scanario is as followings.
Architecture of my application is as bellow.
1. Entry page is LoginPage (.aspx)
2. having login successfully the HomePage appears. (Here we are using a MasterPage and HomePage is displayed as content page.)
3. HomePage(.aspx) is having a UltraWebGrid control
4. Master Page is having a Logout button. OnClick of Logout session is abandoned and page is redirected to LoginPage.
I profiled the application with various tools like .Net Memory Profiler and Ants Profiler after profiling the application I found that MasterPage and HomePage are not being released. When I further drilled down it, I found that MasterPage is not released since it is referenced by HomePage and HomePage is not released by ScriptManager of Infragistics.WebUI.Shared.Util namespace. Call stack is as bellow.
see attachment: Case Number: CAS-24425-CMDQQ1 in your website.
Intrestingly when I replace the UltraWebGrid with .net gridview it releases the memory properly.
I am sure the problem is with ScriptManger class of Infragistics.WebUI.Shared.Util namespace.
Please try to resolve the issue instead of subpressing it with your unreasonable facts so that you could get the good business.
Actually, this won't be necessary. I found the problem and the problem was ours not Infragistics. Since Matt double checked your source code and said the Dispose should be cleaning as expected, I went back into our code and looked much deeper than I initially did and found a case were one of our controls was creating an Infragistics control but not adding it to its' own Controls collection so when it was disposed of the child control (the Infragistics control) was not and that is what the memory profile screen shot was showing. When I saw that, I googled for this issue and found these forum entries and assumed my issue was related. While preventing a control's finalizer from being called and thus preventing the Dispose from being called is a problem, it is not what was leading to our issue. We are using CAB and so when a WorkItem is terminated, its' SmartParts are disposed of so I am not as concerned about having to manually call the Dispose on a control to get this clean up to happen since CAB will do this for us. Long story short, I am once again a happy customer. Although once I cleaned up this issue, I found what looks like a similar issue where we are leaving a UltraWinChart.IGWinTooltip.LocationChangedHookedControls hooked up. I assume we are not disposing of a Infragistics chart control here.