Any Infragestic control you use leaks memory. In testing, I've found that UltraTextEditor, UltraTabControl, UltraComboEditor, UltraButton, etc... All do not dispose of themselves correct and all are held in memory due to a strong reference from Infragestics.Win.Office2007ColorSchemeChangedNotifier, which is held by a static event handler.
Just recently the major memory leaks with win tree were reduced to a point where it could be used in production code. I did a sweep of a couple sub system to use all Infragestic control to take advantage of themeing and when from 20-30k memory leaked per sub system instantiation to 5 megs+ leaked.
Seeing how bad the leaks are, surely someone has a work around? Is there a hot fix for this yet?
I already went over all of that in the ticket. The example provided show cases items being leaked. Support response was that this was by design and that my hamdle/memory leak must be something else. I provided screen shots of my application leakign the same objects, just in much higher numbers, I believe there are 56 instances on 1 object in the screen shots provided. Same objects as in the example., just in greater numbers. My manager is refusign to assign any more time to this project and I've had to revert back to non Infragestic controls, like I have had todo multiple times since 2005 on any consumable control (tool window, dialog, etc...).
The uage for the dialogs follow the using pattern, i.e.
using
(type)) {
pathennessy, I've verified that we are unhooking that event in the Dispose override of the control so either the control is not being disposed, its being removed from its parent before you disposed the parent (this would be ok if you explicitly disposed the listview) or another instance of the control is being created - sometimes this happens inadvertantly when allocating a member variable. e.g. Dim ul as New UltraListView ul = sender as UltraListView
I notice you mention "dialog". Are you showing a form using its .ShowDialog() method? If so, then the .NET Framework won't explicitly dispose the form when you close it. As a result, any controls on the form, and their corresponding resources, may not be garbage collected.
If this is the case, then you should explicitly call Dispose() on your dialog when you're done with it. This will implicitly dispose all controls (including ours) that appear in the dialog's Controls collection (and any controls in their Controls collection).
If that's not the case, then we'll need to investigate this in more detail.
The test case associated with the case leaks window handles and memory each time you open and close the dialog. Same thing happens with my product code, the onyl difference is I leak over 50 handles and a couple megs each time, while with the test case I believe it is only 5 or 6 handles and a few K. Over an 8 hour work day, average usage will have these dialogs opened 240-300 times. With a limite of 10k handles... Well, the software will crash between 100-200 dialog openings.
Regardless of whether it is by design or not. To have *ANY* thing leak after closign the dialog and garbage collection is unacceptable.
Hi, we encountered this issue a while back in vol 7.3 we have a workaround for this issue.
i don't know if it will work with current versions, but you can try.
the solution and explanation of the problem (basically infragistics is rooting all controls to static event handlers) can be found here
(http://subjectively.blogspot.com/2009/03/importance-of-recycling-memory.html)