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
|
Hi There, DataGrid version 6.0 seemed introduce new memory leak after close the control. While version 5.0 does not. In the include image, the cmosrPlusDataGrid is derived from DataGrid from MindScape. And it is for class UcInputGeneral. The memory profile will be sent by email since it is too big to load from here. Memory leak is very important to us since almost all the page contains a DataGrid, please fix them. Thanks Gordon |
|
|
|
|
More screen shot related datagrid version6.0 memory leak. |
|
|
|
|
Hello Gordon Thanks for pointing this out and sending the profile files. The DataGrid memory leak will be resolved in the next nightly build. -Jason Fauchelle |
|
|
|
|
Hi Jason, I downloaded the Jan 21, 2014 nightly build, and the memory leak is the same as before. Thanks, Gordon |
|
|
|
|
Hello Gordon I have not been able to reproduce any memory leak at our end. Please provide more information, or the steps to reproduce. -Jason Fauchelle |
|
|
|
|
Hi Jason, The reproducing project is on thread and the reproduce steps is similar: 1) unzip the file, you may need to change the reference for mindscape dll to your proper address 2) Build application (build it into Any CPU) 3) Run Ants Memory Profile, and point the .Net Executable to this exe 4) Click on butoon "Grid and Chart", the first record on top datagrid is focused. The bottom part will have a datagrid and user control for this bottom part is "UserControlDiscreteData" 5) Now, Click on 4th record with name "Non Param", the bottom is going to show a textblock and UserControlDiscreteData will not be needed. 6) Take a memory snapshot from the profile. On the class list, find UserControlDiscreteData and you will find the memory leak on the DataGrid. please let me know you have problem. Thanks, Gordon |
|
|
|
|
Thanks for the repro project Gordon! This memory leak will be resolved in the next nightly build. -Jason Fauchelle |
|
|
|
|
Thanks Jason, Jan 22 2014 nightly build fix the problem. Hope this will be regular test for you when you have major changes. Out of curiosity, how did you fix it, how the GC handler will have holding up the memory? Thanks, Gordon |
|
|
|
|
Exactly 1 instance of an arbitrary WPF Elements control was being statically held by the license system for validation. I was unable to reproduce this at my end because I was swapping a page of WPF Elements with another page of WPF Elements, so one of the controls on the new page was being picked up by the license system which allowed it to let go of the previous control, thus allowing the memory from the previous page to be collected. But in your repro, you were replacing the content with a non-WPF Elements control (TextBlock), so the control that was supposed to be removed was still being held, which means that the entire visual tree of the previous page was being held up. The fix of course was to release the control after the validation was done. We won't need to make changes to the license system, so this can't happen again. Thanks again for the repro project. -Jason Fauchelle |
|
|
|
|
Hi Jason, There is a new memory leak when you have Grouping header/panel. You may reproduce it with the one I sent to and let datagrid allow grouping and Drag a column header to Grouping area. The included is the screenshot about the leak. Thanks, Gordon |
|
|
|
|
Thanks Gordon This will be resolved in the next nightly build. -Jason Fauchelle |
|
|
|
