Hi
After researching a problem i had where contextmenu's do not draw properly - i discovered that it happened when i had screens open which contained either the UltraDayView or UltraMonthViewSingle.
It seemed to me that the infragistics schedule controls was using way too much gdi resources so that not even other applications context menu's were rendering properly.
Further digging got me to this article;http://subjectively.blogspot.com/2009/03/importance-of-recycling-memory.html
Is what this person saying true?
Why on earth would you sacrifice application stability (the most important thing of all) for such a trivial convenience as updating the UI when the windows theme changed.
Can somebody please tell me whether this issue mentioned in the above link has been addressed in the latest version?
What Mr. Naar neglected to mention in his blog is that if you dispose of the controls properly, as is good practice, the references are released, nothing stays rooted, and there is no leak. If I remember correctly he was using finalizers, which is (at least in the opinion of some of the folks at Microsoft) not recommended. You can read more about that here if you like.
Having said that, it is possible that a Pen or a Brush is not being disposed of properly, in which case you should report it as a bug.
I've been using these controls for a while now, and i have never read anywhere that i should be calling Dispose on each infragistics control to ensure no memory leaks. Isn't one of the advantages of the managed environment that you dont have to call dispose on every control you create on a form when you close it? Certain objects yes, but your controls on a form should automatically be garbage collected when they go out of scope right?
I still am very curious as to why someone made the design descision to create all UI elements as unmanaged. Is there any good reason for this because it seems like a complete breach of good coding practices and is inevitably going to cause memory leaks for people who don't dispose every control they create. What was the reason for this? Was it simply to enable the theme changing?
The Form class's Dispose method calls Dispose on every IDisposable implementor in its Controls collection (and nested Controls collections therein), so you don;t necessarily have to explicitly call dispose on every control on a form
Does this only happen when we explicitly call Dispose on the form's instance (as opposed to simply leaving it to the garbage collector after it goes out of scope)?
but the fact that this is default behavior for a Microsoft implementation indicates (to me at least) that this is good practice.
I would agree with that. I'm just trying to be clear on what we are supposed to be explicitly disposing
contact said:(which, lets face it - not many people do call Dispose on every control on their form when they close it)
To answer the question: yes, if Dispose is not called on the control, it can result in a memory leak.
I would agree that for objects like database connections you should always call Dispose. But is it really common practice to call the Dispose method for each control on a form? Or should we only call Dispose for infragistics objects?
Yes, the issue of rooting controls that are not disposed of is caused by our hooking the theme changed events, but this does not constitute unmanged code.
Does all this mean that unless you specifically call Dispose on the object (which, lets face it - not many people do call Dispose on every control on their form when they close it) then it will result in memory leaks?
contact said:Isn't one of the advantages of the managed environment that you dont have to call dispose on every control you create on a form when you close it?
"One problem with this system is that the garbage collector does not run deterministically and, as a result, your object may not be finalized for a long time after the last reference to it has gone away. If your object holds onto an expensive or rare resource, such as a database connection, this may not be acceptable. For instance, if your object has 1 of only 10 available connections open, it should release that connection as soon as possible, rather than waiting for the garbage collector to call the finalize method."
(source: CLR Inside Out by Shawn Farkas, MSDN Magazine, July 2007)
contact said:I still am very curious as to why someone made the design descision to create all UI elements as unmanaged.
contact said:...is inevitably going to cause memory leaks for people who don't dispose every control they create.