Hello !
I believe that almost all infragistics controls have memory leak issue. I have discovered it because my application is using to much memory so i have invastigated first on my application and next by making some simple examples(using only one or two control) and using a memory profiler.
Now, the problem is that every infragistics control is referenced by a delegate called "themeChangedDelegate" and as a conseguence the GC cant return that memory to the OS. if you are not aware of this problem and cannot replicate this issue, i can make a video with a very simple example.
Hope to see fixed this issue as soon as possible.
Thank you.
Best Regards.
ps: i'm using 2008 vol2.
I noticed a similar problem with the winGrid 8.2 in my example email application but the memory problem went away in 8.3 not sure about the other controls but the memory problem i was facing has disapeared... I just tried to replicate the memory leak that you are refering to as mine was something different but could not find a leak in the themeChangedDelegate delegate so I for one would be interested in a video example so I could test it on my machine to...
Hi Bishop,
here are the videos.
http://www.focuslab.eu/public/infragisticsmemoryleak/t1/t1.html
http://www.focuslab.eu/public/infragisticsmemoryleak/t2/t2.html
Couple of things, first the reason you see Form in "Shortest root path" is because it is part of .Forms... Custom dll files, controls etc. are not part of those objects...
Setting a object to Null does not mean that the GC is going to collect it, furthermore the GC.Collect method is not guaranteed to Collect nor destroy objects in memory as it has a mind of its own, however setting a objects IDisposable and/or Object.Dispose does allow the gc to clean up a little better than Null.
I am pretty swamped this weekend but will try to get to making a video to show what I mean and does not produce the same results as your videos.
Chris Bishop said:Couple of things, first the reason you see Form in "Shortest root path" is because it is part of .Forms... Custom dll files, controls etc. are not part of those objects... Setting a object to Null does not mean that the GC is going to collect it, furthermore the GC.Collect method is not guaranteed to Collect nor destroy objects in memory as it has a mind of its own, however setting a objects IDisposable and/or Object.Dispose does allow the gc to clean up a little better than Null. I am pretty swamped this weekend but will try to get to making a video to show what I mean and does not produce the same results as your videos.
first,
if you have an instance of a class(aka object) referenced only once and than set to null that reference, that instance is going to be destroyed as first as the GC see that it is no longer referenced.
second,
calling Dispose method it does not mean that the GC "Clean up" better the memory! The purpose of IDispose is that the class which implements it
is using unmanaged resourses so the programmer of the class must take care of this because the GC cant do this job!
It would seem that your knowledge of what dispose actually does is amazingly superior to mine so forgive my attempt at trying to help you understand, you have my deepest apologizes for my total Noob answer.
Thanks for the most excelent information about how Null/Nothing works "in C# / VB.NET" I guess I am just confused with how VB6 handles objects.