I had already read that thread.  The controls that are leaking are on a pop-up dialog that is in a using statement.  I have verified that the form dispose is being called and I explicitly called dispose on all of the ultraButton as a test and use a try finally around the using statement and

GC.WaitForPendingFinalizers();

To insure everything is freeded.  However, memory still leaks and I used dotTrace from jetBrains to track down why.  Thee is a static class member than holds a reference to an event handler for colorSchemeChanged on every ultra control I use.  That event is linked to Office2007ColorSchemeChangedNotifier.  The thread you pointed me too has the exact same problem and was indentified in June 2008. Yesterday I installed the latest hot fix and hte problem still persists.  I'm shock that after 8 months there is still no fox or work around for this. :(

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.

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.

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)) {

I'm not sure if this is the same case but a recent memory leak report that I reviewed had a screenshot of a dotTrace output. The majority of the things in the screenshot were AppStyling related objects that are statically stored. These are not memory leaks. As you created and showed multiple instances of a form, those would not increase - it was a one time hit as the application styling metadata for the assemblies were loaded. The other things I saw in that were UltraWinTree classes but the main window that was still displayed contained an UltraTree so that is why those objects were there. Again, perhaps this is a different case but I just double checked the code and the event you mentioned in the initial post is hooked in the ctor of the UltraControlBase (the base class for controls such as UltraButton, UltraListView, etc.) and unhooked in the Dispose method of the UltraControlBase so as long as the Dispose method is called then that method will be unhooked. Can you post the sample project you provided with which you are seeing the issue?

I have confirmed the Infragistics controls are being disposed of but yet are not being GCed due to the hookup shown in the dotTrace screen shot.  We are using the AppStyling runtime and we load 2 different style files (isl files).  One style file has the styles that are shared between all of our applications and one style file has the styles specific to a particular application.  I haven't had time to try a couple of different things or build a sample app.  I'll try to get to it this weekend.  Unfortunately, I have a client starting a new application development effort and I can't recommend the control suite until this is resolved.

I was wrong.  We had a case were we weren't disposing of an Infragistics control so 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.