This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have a a templated propertygrid instance bound to a data object that implements System.ComponentModel.INotifyPropertyChanged interface. The template I am using is a slight modification to Poppy provided in your samples. The propertygrid's get its data from the DataContext property of its parent user control. When the propertygrid's parent user control is unloaded, I call the following method: BindingOperations.ClearAllBindings(this); in an attempt to clear all bindings associated within this usercontrol, in particular those associated with the propertygrid but this does not make the propertygrid and its parent usercontrol eligible for garbage collection. Have you guys ran into this problem? |
|
|
Mindscape, would you please comment on the above question? Anything will help as I am not getting anywhere with this. To duplicate do this: Modify your sample files as follows: Poppy.Xaml.cs: public partial class Poppy : Window
Launcher.Xaml.cs: Add button with the following handler attached to its Click event. private void Button_Click(object sender, RoutedEventArgs e)
Compile, run, open Poppy, close, the click on button to collect invoke GC. Observe that 50M of memory is not released. |
|
|
Hello Klaus, We have reproduced the problem and are investigating. We will comment as soon as we have a fix or workaround for you. |
|
|
Hello Klaus, Just to update you on this. We have been investigating this and we believe we are close to a fix but it will not be in time for tonight's nightly build. We should have something for you by tomorrow night's build, and will keep you posted. |
|
|
Much appreciated. |
|
|
Hello Klaus, We have now implemented a candidate fix for this and it will be in nightly builds dated 21 Nov 2008 and above. However, although the core of the problem was due to leaks within our code, we found that there appeared to be some WPF infrastructure issues which caused references to be held under what seemed to be arbitrary circumstances: these are obviously outside our control and we can therefore only offer workarounds. For example, we had a line of code within the grid that set the IsSelected property of a TreeViewItem to true. Even though this line does not appear create a reference to any of our objects, the leak would not go away as long as it remained! Similarly, you would not expect the various borders and panels surrounding a template to affect memory release, but we found that they did, and for the time being we are at a loss to explain why. So here are the changes you should note in the Poppy sample: * Poppy template now contains some new elements. (The default template has also been changed slightly.) These changes are to work around the issues noted above and we would advise carrying these across to your own custom template. * The SelectedObject needs to be cleared in order to get WPF to release its references to the nodes, which would otherwise keep the grid and therefore the window in memory. (These references should be weak, but in practice the WPF PropertyChangedEventManager refuses to release them.) For now, you need to do this from user code when you no longer need the grid instance. The reason we cannot do it internally in our Unloaded event is that WPF controls may go through unload-reload cycles during their life (e.g. if the system theme changes): we do not know if an Unload is a disposal or just a theme change, so we need to hang onto the selected object reference even during unload. You will also need to use the new binaries (or recompile from the new source), as we have made some code changes too, mostly around moving from direct CLR event hookup to the XxxEventManagers and weak event pattern. I have also found that not all memory gets released on the first GC. You may need to press the "collect" button two or three times (I have never needed more than three). Note that calling GC.Collect and GC.WaitForPendingFinalizers in a loop does *NOT* have the same effect; it does seem to take a bit of time before the window becomes eligible for collection, possibly to do with some sort of asynchronous cleanup within the WPF binding infrastructure (I am speculating here). Thanks for reporting this issue and please let us know if this does not fix it for you. |
|
|
Excellent work Ivan. Thank you.
BTW, how do I download the Non-trial version of nightly builds? |
|
|
Never mind, I got the nightly build. |
|
|
Guys, The nightly builds I keep downloading from here: https://www.mindscape.co.nz/Store/Download.aspx?c=56746105-1e62-4fde-ab9f-13362b34d2c6 named ElemCombo-20081112.zip does not contain the changes Ivan mentioned in this thread.
|
|
|
Klaus, Could you please try now - it should be labeled as 20081125. I hope that helps, John-Daniel |
|
|
Excellent work guys. W Download updated, performed test and memory is being released as expected. Will take some pointers from Ivan's note when designing my own custom templates. |
|