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.
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 have developed a Silverlight application. It has a button and once it is clicked the application starts doing something which takes time. Since everything in Silverlight is asynchronous the UI is not lagging, however, I would like to add some animation to it or something else to indicate that the application is actually doing some work and that the user should wait.
I don't know how to implement this, neither thread nor XAML wise. What is the best approach to this? Thanks.
Silverlight 4 wait/spinner control
Or if you are using MVVM
Generally Preferred Method for a 'Wait' Screen using MVVM and Silverlight
You can get the busy indicator control out of the Silverlight Toolkit:
http://silverlight.codeplex.com/
I have been developing a Lync Silverlight application in Silverlight and now I am trying to shift it to WPF.
However, I am facing some thread affinity issues. For example I display the Lync client's state on my page in a textblock, and so in my code behind have wired a state changed event handler, that writes the new state into the textblock whenever the state of Lync client changes.
Now, this worked perfectly in silverlight but seemingly is not allowed in WPF.
Now my questions are:
How come it works in Silverlight bt not in WPF, even though Silverlight is supposed to be a subset of WPF?
Thread affinity is an important concept and I know we can use invoke dispatcher, but doesn't it just beat the concept of asynchronous programming in form of event handlers and callbacks?
I have a button defined in my XAML page, and the click event handler defined on it can access other UI elements, it does not suffer the problem outlined above.
But if I define a LyncClient instance in my code-behind, event handlers defined on it cannot access the UI elements. Why so, I detected no such difference between UIElements and other objects in Silverlight?
Based on above comments, I'll suggest the following "answer"...
I would guess it is more likely than not that there is some sort of different in the way that the SL API was written than that of the WPF api. That could explain the difference in the thread that is used when the API issues the callback. To verify this, you could:
Ask MS directly
Put some diagnostics code in your callback method to log the thread ID and compare that to the main thread of the application. Do this for both SL and WPF to see if they are the same or different threads.
Open the assemblies in Reflector to inspect how each API was written.
In terms of handling this specific situation, in your callback, you could:
Get the dispatcher object (different for SL than WPF) and always issue UI updates through Dispatcher.Invoke.
Use databinding and INotifyPropertyChanged to insulate the UI from the property. You could delcare a property on a ViewModel or in the code behind. Then bind the UI's textbox to that property. Databinding has some smarts in it that will automatically marshal property changes to the correct thread (in most cases anyway).
Hope that helps.
I have what, on the face of it, seems to be a really simple requirement - to be able to show a messagebox from within the view model of my WPF prism application.
Reading the documentation everything sounds good when I'm reading about Interaction Requests but I then find out that WPF doesn't support PopupChildWindowAction.
How are people getting around this. Basically I want a Messagebox in my shell module / or a infrastructure module that will subscribe to events and popup when that event is published.
Another issue I had was I want the popup to be centered on the parent window (the shell).
Just wondered how other people approached this. There seem to be a number of different ways to go but neither seem to fit the bill exactly.
From A CodePlex post by Karl Shifflet:
I've written a WPF version of the Interaction Request for my the Box MVVM Training here:
http://visualstudiogallery.msdn.microsoft.com/en-us/3ab5f02f-0c54-453c-b437-8e8d57eb9942
Install this Visual Studio Extension.
Create a new project with the MVVM Training Template.
Check out DialogInteractionRequestView.xaml and its implementation.
Cheers,
Karl
Use the RegionPopupBehavior from Prism 2.2 RI.
Use the EventAggregator in PRISM to subscribe to events, and have an in-memory presenter that listens for an event and then creates a view using the event data and calls ShowDialog on the view.
The dialog result can then be used to publish a 'response' event that would be routed back to the process that initiated the event that resulted in the display of the dialog.
Since PopupChildWindowAction is only in Silverlight, I have created my own PopupAction by inheriting from TriggerAction class and simply overridden body of Invoke() method to bring up a PopupWindow where I can pass any UserControl from xaml within the prism interaction trigger tag. From within ViewModel I am raising interactivity request event which triggers my PopupAction in view and opens the popup with desired user control being displayed onto it. Seems to work. I'll need to polish the example more. But here is a link -
http://wpfgrid.blogspot.com/2013/01/simple-prism-mvvm-way-to-display-dialog.html#step3
I'm building a custom Silverlight UserControl which needs to listen to events using Preview/Tunneling, but for some reason the compiler is telling me they are not recognized or accessible.
For example, I can add an event handler to MouseLeftButtonDown, but not PreviewMouseLeftButtonDown. This doesn't make sense because according to Microsoft (http://msdn.microsoft.com/en-us/library/system.windows.uielement_members(v=VS.100).aspx) all UIElements should have Preview events attached.
Any ideas as to why this is happening? I'm using Visual Studio 2010 Trial, Blend 4 RC and .Net 4, if that makes a difference.
Silverlight does not support preview events nor does it support routed events (bubbling/tunneling) except for a few core events.
If you are trying to create a control that works with both WPF and Silverlight, you will need to take a different approach. Depending on what you're trying to do, you may be able to accomplish what you want by rigging up a handler in code and specifying that you want handled events too.
// the last parameter indicates we want to receive events that
// were marked as e.Handled = true by other listeners
// this type of event handler can only be done in code
myUserControl.AddHandler(
UIElement.MouseLeftButtonDownEvent,
OnMouseLeftButtonDown,
true
);
You're looking at the help for WPF, not Silverlight. Silverlight is (mostly) a subset of WPF, and much of the functionality is missing.
The Silverlight UIElement help does not show those events, as they do not exist in Silverlight.