Emily Fong
Top achievements
Rank 1
Rank 1
Emily Fong
asked on 08 Feb 2012, 12:30 PM
Hi,
We am using Telerik Reporting Q3 2011 on .Net Framework 4.0.
We found that the reportviewer cannot be released from memory even the form have been closed.
By using the .Net Memory Profiler, we know that there is a event handler for "ToolStripTextBox" in reportviewer control which does not been removed after the form closed. So, "Disposed instances with direct EventHandler roots" problem occurred.
After testing, we found that only if we set the "ToolBarVisible" property to "False" in ReportViewer control, the memory can be released successfully.
So, any advise?
Thanks!
Emily
We am using Telerik Reporting Q3 2011 on .Net Framework 4.0.
We found that the reportviewer cannot be released from memory even the form have been closed.
By using the .Net Memory Profiler, we know that there is a event handler for "ToolStripTextBox" in reportviewer control which does not been removed after the form closed. So, "Disposed instances with direct EventHandler roots" problem occurred.
After testing, we found that only if we set the "ToolBarVisible" property to "False" in ReportViewer control, the memory can be released successfully.
So, any advise?
Thanks!
Emily
7 Answers, 1 is accepted
0
Hi Emily,
We reviewed your thorough feedback (for which we are grateful) and after some research we found that this memory leak is indeed a problem with the MS ToolStripTextBoxControl control. You can review the following blog post that explains what is the problem and possible suggested "fix".
We would take some more time to research if there is an easy way to address this in our code and if so would address this in a subsequent version of the product.
All the best,
IvanY
the Telerik team
We reviewed your thorough feedback (for which we are grateful) and after some research we found that this memory leak is indeed a problem with the MS ToolStripTextBoxControl control. You can review the following blog post that explains what is the problem and possible suggested "fix".
We would take some more time to research if there is an easy way to address this in our code and if so would address this in a subsequent version of the product.
All the best,
IvanY
the Telerik team
Sharpen your .NET Ninja skills! Attend Q1 webinar week and get a chance to win a license! Book your seat now >>
0
Stargazer
Top achievements
Rank 2
Rank 2
answered on 19 Apr 2012, 10:09 AM
Hello there!
I'm wondering if there's been any development in this issue?
I'm using Q3 2011, so I'm facing the problem. Even tried the "fix" provided to no avail (though I am investigating still if there is something else causing the leak).
Regards!
I'm wondering if there's been any development in this issue?
I'm using Q3 2011, so I'm facing the problem. Even tried the "fix" provided to no avail (though I am investigating still if there is something else causing the leak).
Regards!
0
Stargazer
Top achievements
Rank 2
Rank 2
answered on 19 Apr 2012, 11:00 AM
Well, after some more digging, the "fix" suggested in the blog post mentioned earlier, does not resolve the issue. Anyone else has tried that?
See attached pictures to contextualize, where "snap.png" is the portion of the JustTrace snapshot that matters, "code.png" is the code of the report viewer form' constructor and "state.png" is the application after closing of the report viewer form.
Regards!
See attached pictures to contextualize, where "snap.png" is the portion of the JustTrace snapshot that matters, "code.png" is the code of the report viewer form' constructor and "state.png" is the application after closing of the report viewer form.
Regards!
0
Hi Nuno,
In the related blog post there are actually two fixes, because there are two possible scenarios for memory leaks.
The first problem has quite long explanation, but long story short - when the control is part of a container the OnVisibleChanged event is called only when the control becomes visible. This means that when ToolStripTextBoxControl becomes hidden no event handler will be removed and once it becomes visible again another event handler will be added. The Dispose method will remove the event handler, but it will remove only one event handler and if the control has changed its visible state more than one times the Dispose method will not get rid of the rest of the event handlers.
At the bottom of the page there is a sample code of how to deal with the problem and there are explanations in the blog post on the two possible ways you can use it.
The second problem is related to the VisibleChanged event and ToolStrips - when the Control is disposed the VisibleChanged event will be raised and this can cause several UserPreferencesChanged
event handlers to be added, which will never be removed (the Control is already disposed).
There is a link for that problem in the blog post.
From your explanations it is not clear what fix did you apply, how did you implement the solution in your code, what are your scenario and setup, etc. Therefore it will be best if you provide us with more information. The best will be to send us a runnable sample that exhibits the problem so that we could debug it at our end.
Also as the problem is related to the .NET Framework and not Telerik Reporting it will be very hard to provide a solution that works for everyone - therefore we will take the time needed to address this issue and if there is a proper way to address it in our code we would fix it in a subsequent release.
Regards,
IvanY
the Telerik team
In the related blog post there are actually two fixes, because there are two possible scenarios for memory leaks.
The first problem has quite long explanation, but long story short - when the control is part of a container the OnVisibleChanged event is called only when the control becomes visible. This means that when ToolStripTextBoxControl becomes hidden no event handler will be removed and once it becomes visible again another event handler will be added. The Dispose method will remove the event handler, but it will remove only one event handler and if the control has changed its visible state more than one times the Dispose method will not get rid of the rest of the event handlers.
At the bottom of the page there is a sample code of how to deal with the problem and there are explanations in the blog post on the two possible ways you can use it.
The second problem is related to the VisibleChanged event and ToolStrips - when the Control is disposed the VisibleChanged event will be raised and this can cause several UserPreferencesChanged
event handlers to be added, which will never be removed (the Control is already disposed).
There is a link for that problem in the blog post.
From your explanations it is not clear what fix did you apply, how did you implement the solution in your code, what are your scenario and setup, etc. Therefore it will be best if you provide us with more information. The best will be to send us a runnable sample that exhibits the problem so that we could debug it at our end.
Also as the problem is related to the .NET Framework and not Telerik Reporting it will be very hard to provide a solution that works for everyone - therefore we will take the time needed to address this issue and if there is a proper way to address it in our code we would fix it in a subsequent release.
Regards,
IvanY
the Telerik team
BLOGGERS WANTED! Write a review about Telerik Reporting or the new Report Designer, post it on your blog and get a complimentary license for Telerik Reporting. We’ll even promote your blog and help bring you a few fresh readers. Yes, it’s that simple. And it’s free. Get started today >
0
Stargazer
Top achievements
Rank 2
Rank 2
answered on 24 Apr 2012, 01:23 PM
Hi,
Yes, sorry about that. :)
The fix I've applied is the one with the source code on the blog post, the one that implements a "special" class to keep track of the handlers created. I've used the static helper method to do so, as explained in the post.
Regarding the other issue described in the provided link, in fact, I did not try nothing about it. I'll try that and see what I can get.
Thanks.
Yes, sorry about that. :)
The fix I've applied is the one with the source code on the blog post, the one that implements a "special" class to keep track of the handlers created. I've used the static helper method to do so, as explained in the post.
Regarding the other issue described in the provided link, in fact, I did not try nothing about it. I'll try that and see what I can get.
Thanks.
0
tung ngie
Top achievements
Rank 1
Rank 1
answered on 05 Jun 2013, 08:19 AM
Dear Ivan
Is this fix in Q3 2012?
Thanks!
Is this fix in Q3 2012?
Thanks!
0
Hello Tung,
As explained in the previous post and as you may see in the blog post the issue is related to the .NET Framework and not to Telerik Reporting. Therefore it will be very hard to provide a solution that works for everyone and currently there is no clear idea on how this can be achieved. You can follow our release notes in case there is a change.
Regards,
IvanY
Telerik
As explained in the previous post and as you may see in the blog post the issue is related to the .NET Framework and not to Telerik Reporting. Therefore it will be very hard to provide a solution that works for everyone and currently there is no clear idea on how this can be achieved. You can follow our release notes in case there is a change.
Regards,
IvanY
Telerik
Have you tried the new visualization options in Telerik Reporting Q1 2013? You can get them from your account.