I've just been investigating some Silverlight controls with ANTS Memory Profiler (brilliant!) and found out that some of my controls are staying around in memory. The solution to this has been to reset the Template and Content values to null when control 'Unloads' and to clear any Bindings I've done in code.
Is this the normal pattern for dealing with Silverlight custom controls and have I just failed to do this properly in the past?
Does anyone know of a paradigm e.g. of the pattern for writing Silverlight controls with tidy clean-up?
Addendum I've been investigating this further and found that Bindings to the DataContext are removed when the DataContext is set to null. It seems that the correct procedure is to set any Datacontext value in the Loaded event and set it to null in the Unloaded event. I've still got a fundamental problem with the paradigm for writing Silverlight Templated controls as I just can't force ContentControls to be destroyed (see my issue here: Why are Silverlight ContentControls not garbage collected?).
MS has released Silverlight 4 GDR3 that includes memory leak fix's
I'm not sure if this fixes your case but it is worth downloading the latest SL version and testing again.
http://timheuer.com/blog/archive/2011/02/14/silverlight-february-2011-update-gdr3.aspx
Did you recognize where is leak? Is it in your or in MS code?
Here is good post about leak detecting in SL: http://dotnetspeak.com/index.php/2010/09/using-windbg-to-find-memory-leaks-in-silverlight-applications/
My problem appears to be associated with my desire to have re-loadable controls. I've asked the question again in more detail here: Should Silverlight Controls be re-loaded onto pages?
Related
In WPF and WinRT it is well known that behaviors do not call their Detach method reliably. The only way to avoid a memory leak is to subscribe to the Unloaded event of the AssociatedObject and unhook all events (example).
So far it works.
But I realized (as did someone else who commented on the blog entry I linked) that in this way unloaded behaviors are never attached again. Take a MenuFlyout for instance. If there is a behavior attached to a MenuFlyoutItem it is unloaded when the MenuFlyoutItem is closed. If you open the Menu again it won't be reattached.
This also happen with other UserControls. I "lose" behaviors when navigating in my WinRT App from one Page to another and back again although all Controls are recreated anew. I don't see how I can use them in a WinRT App where a lot of Controls are recreated by navigating around.
Is there any solution known to this?
A big thanks to #Justin XL, Microsoft has updated the Behaviors SDK for UWP and made it open source. The new libraries fix the navigation detach problems! :)
http://blogs.windows.com/buildingapps/2015/11/30/xaml-behaviors-open-source-and-on-uwp/
https://twitter.com/hashtag/BehaviorsGoOpenSource?src=hash
I am using Silverlight WebBrowser Control in one of my application, and all the Silverlight Content hides behind the WebBrowser Control.
I know, we can't do anything about it and have read about the Air Space Issue also. I have also gone through the following links:-
How to place a WebBrowser control below other controls?
But its really required to solve it for my application, so I am looking for some alternatives, either FREE or can be PAID too.
I have read about the FireFox Gecko browser, but it seems it is a pure Windows Forms Control and I wonder whether I can use it in Silverlight or not, and also whether it will solve the z-index issues if we can at all use it in silverlight.
Does any body has any solution for this ? Either Free or Paid.
Thanks
Awesomium is a fairly decent browser since it uses chrome as it's base and it's a native control for WPF so it'll respect your z-index. However, it's a wpf control right now and it's not clear if SL is easily supported or not, but this may help.
Awesomium website: http://awesomium.com/
some mention on how to get a silverlight dll to use:
http://support.awesomium.com/discussions/questions/119-using-awesomium-with-silverlight-40
I am having an issue with repaint of my WPF control.
The WPF control is added as an ElementHost.Child for a Windows form.
When Windows 7 goes into powersave mode and is brought back to normal (by moving the mouse or key press on keyboard), the rest of Windows form controls are repainted, however the WPF part is not repainted(and the Win 7 background is visible in that area).
On Minimize and maximise of the application, the WPF part is repainted.
Anyone has any idea about this problem?
The solution for this issue was provided in MSDN magazine a while back. It shows how you can make your WPF applications "power-aware" i.e. respond to power notifications. It's an amazing article and a "must-read".
Check this link: Make Your WPF Apps Power-Aware
You can browse the source code online or download it from here: Code for PowerAware
Technologies used:
WPF
.Net Framework 3.0
Windows Vista / Windows XP
Generally, in windows forms calling .Invalidate() on a Control will cause it to repaint itself (via setting the entire control's validation rect to "dirty" and then letting it invoke its own paint event asynchronously. -- If you just invoke the Paint method in winforms without Invalidating first, you will only be able to redraw the portion that was previously marked as dirty -- as windows uses the Dirty Rectangles approach to save on redraw time.)
Hopefully you can either call .Invalidate() on your WPF host control or just call .Invalidate() on the form itself (e.g. "this.Invalidate();")
Enabling double buffering on your form might also help, but I am unsure of this -- it's worth the experiment though.
#Hasan above gave you part of the answer -- how to hook into the windows message pump which and receive windows power event notifications -- but by itself will not cause your window to be repainted (at least from what I can tell) -- it's more of a notification that says "hey, you're about to have that problem you hate. Sucks to be you."
So this is probably as simple as hooking into Hasan's message pump stuff and then calling "this.Invalidate();" any time a power event notification is received. Though that solution may be a little bit overkill.
If that's not enough you may have to tell the WPF control itself to Invalidate... which it can't do, because it doesn't have that method. The documentation suggests that .InvalidateVisual() is the equivalent, but my experience has lead me to believe otherwise. Other than invalidating at the winform's level, I can't help you. If you find the answer, please post it!
When hosting WPF user controls within a WinForms MDI app there is a drawing issue when you have multiple forms that overlap each other that causes very distinct visual artifacts. These artifacts are mostly visible after dragging one child form over another one that also hosts WPF content or by allowing the edges of the child form to be clipped by the main MDI parent when dragging it around. After the drag and drop of the child form is completed the artifacts stay around generally but I've found that setting focus to a different application's window and then refocusing back on to my application window that it is redrawn and all is good again until the child forms are moved once again. Please see the image below which demonstrates the problem.
Those at Microsoft insist that the WinForms MDI is already a sufficient solution for MDI and doesn't need reinventing in WPF although I find it hard to believe they tried creating a WPF app this way because of the obvious shortcomings.
UPDATE: A few extra notes that I left out is that if I create these Forms without setting the MdiParent they are created as regular forms and this issue doesn't happen. This issue seems unique to the WinForms MDI scenario. Also I've currently running on Windows 7 Enterprise and I'm aware the results may be quite different on Windows XP but I haven't been able to test this.
UPDATE: I've found a few other related resources on this issue that I thought I should share.
elementHost repaint problem in MDI
application
elementHost repaint problem in MDI application on Tech Archive
It appears that another workaround is to revert to software rendering as opposed to taking advantage of hardware acceleration. This was the suggestion by Marco Zhou on the MSDN Forums.
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
this.Loaded += delegate
{
var source = PresentationSource.FromVisual(this);
var hwndTarget = source.CompositionTarget as HwndTarget;
if (hwndTarget != null)
{
hwndTarget.RenderMode = RenderMode.SoftwareOnly;
}
};
}
}
I've tested this and this solution seems to work very well and so far is the only solution that I've found for solving this problem within a FoxPro interop scenario which is very similar to the WinForms one I posted about originally. For now I'm planning to use my original Refresh on the MDI Parent solution for my WinForms project but then for my other native interop applications such as when my WPF controls are hosted in Visual FoxPro I'll use this solution. That is unless of course if a more elegant solution is discovered for either of the cases.
Also it's important to note that from what I'm aware software rendering is the only option on XP systems and normally Visual FoxPro nore WinForms normally take advantage of the same type of hardware acceleration that native WPF apps do on Vista OS and up. So using this option may not be as bad as it sounds when you do have to deal with interop. Currently I'm not aware of any related side effects when using this solution but if there are any those would have to be taken into serious consideration.
Well, I may have found a solution although it feels like a bit of a hack. It appears that if you call the Refresh method on the MDI parent whenver a child MDI Form is moved that the noted artifacts go away. Visually things appear a bit jittery when dragging a window but it seems much more acceptable than the example I showed in my original post.
private void Form1_Move(object sender, EventArgs e)
{
this.ParentForm.Refresh();
System.Diagnostics.Debug.WriteLine(string.Format("Form Moved to: ({0},{1})", this.Left, this.Top));
}
I've tried many combinations in the same vein such as refreshing just the child window that was being moved by calling methods such as Update(), Invalidate(), Refresh() and also I've tried these same methods on the MDI parent as well as Dispatcher.Invoke(DispatcherPriority.Render, ...) and InvalidateVisual() on my hosted WPF control but none of those other methods worked accept for calling Refresh() specifically on the MDI parent.
I realize that this probably isn't the optimal solution since I'm forcing the whole main application window to refresh every time a child window moves a few pixels but as for right now it's the only reasonable solution that I found that works. If anybody else has any alternative solutions or any improvements upon this I will gladly accept your answer instead.
Check video drivers and try disabling hardware acceleration. Most artifacts are caused by bad drivers, failing video card, or insufficient time to complete the refresh.
First troubleshooting step: Update video drivers. Obvious, I know.
I had similar issue, checking my video card settings (NVidia Control Panel) showed global setting set very high causing a longer refresh interval which may be aborted if taking too long. Setting my settings back to defaults resolved most of the issue. But I also run hashing programs which use the GPU intensely so this is likely the cause of my remaing artifact issue which is very seldom now and mostly shows its ugly face in Visual Studio.
Another troubleshooting step I ran across is to disable hardware acceleration for WPF, this can be done in 'HKEY_CURRENT_USER/SOFTWARE/Microsoft/Avalon.Graphics', or maybe an application can do it BUT this is only for troubleshooting; never set these within an application because it will disable for ALL WPF applications. I do not have this registry setting nor did I add it so I am not sure of the success with it, but many say this resolved their issue. Also note some applications have this option available, try disabling it if available.
Another troubleshooting step is to make sure the video card is a proper tier level for rendering. Any card that supports DX9 or greater should be sufficient, but other factors are involved (as is my case) so just because it is on the list does not mean it is adequate for your purpose.
Finally, you can use the Visual Profiler (part of Windows SDK), and other tools, to help determine what is going on more precisely with WPF lacking performance in relation to graphics ability.
Rendering Tier level notes and WPF Performance information --> http://msdn.microsoft.com/en-us/library/vstudio/ms742196(v=vs.90).aspx
Hope this helps someone.
--Ryan Strassburg
Your usercontrol or window loaded event ;
this.WindowState = System.Windows.WindowState.Minimized;
this.WindowState = System.Windows.WindowState.Normal;
it may seem bad solution. no need to hit your head against the wall.
A Turkish proverb says: the best code is the code is running :)
Silverlight 2 is missing the unload event for a UserControl. Has anyone implemented a workaround for this?
you might want to look here:
http://gallery.expression.microsoft.com/en-us/SLUnloadedBehavior
The code is for SL 3 but if you remove the behavior code it should work for Sl2
#KeithMahony
One scenario is that you want to prevent event memory leaks, one of the pitfalls of silverlight development that most people tend to ignore.
I think the closest you'll get is Application Services which let you detect when the Silverlight application is closing and respond to it. If you're using a Navigation application then you can hook into the Navigating event of the parent frame to determine that the page is "unloading".
What are you trying to do that requires a UserControl to respond to an unloading event?
Consider using Silverlight 4. I comes with - at last - an Unloaded event.