Thinking about threading in Silverlight 4, we choose between the two options
Also there are times where we need to manage the threads manually. Since Silverlight runs in a Single threaded apartment (STA) application model and the default is the UI thread, accessing the UI objects from other thread leads to cross thread exception. Knowing this fact I worked with a secondary thread and updated a property in my ViewModel. In that scenario I got an exception and digging into the inner exception found out the cross thread exception. For understanding I've created a sample scenario that raises exception.
Snippet 1
Then examining the cause, realized that the specific property raises an property changed notification . Immediately recalled the excellent article from Pete Brown in his 10rem.net blog.
The following implementation does the trick.
Snippet 2 (Just replace the INotifyPropertyChanged implementation)
When I typed "Deployment.Current.Dispatcher.", it didn't show up the "CheckAccess()" method in the intellisense. But I verified it in the object which shows the existence of the method. So I manually typed the "CheckAccess()" method name and got complied without error.
References
http://10rem.net/blog/2012/01/10/threading-considerations-for-binding-and-change-notification-in-silverlight-5
- Background worker
- Managing thread manually
Also there are times where we need to manage the threads manually. Since Silverlight runs in a Single threaded apartment (STA) application model and the default is the UI thread, accessing the UI objects from other thread leads to cross thread exception. Knowing this fact I worked with a secondary thread and updated a property in my ViewModel. In that scenario I got an exception and digging into the inner exception found out the cross thread exception. For understanding I've created a sample scenario that raises exception.
Snippet 1
public partial class ThreadTest : UserControl, INotifyPropertyChanged { private string textValue; public string TextValue { get { return textValue; } set { textValue = value; NotifyPropertyChanged("TextValue"); } } public ThreadTest() { InitializeComponent(); InitControls(); } private void InitControls() { this.DataContext = this; } private void Direct_Click(object sender, RoutedEventArgs e) { TextValue = "direct text......"; } private void UsingTask_Click(object sender, RoutedEventArgs e) { Thread secondaryThread = new Thread(SecondaryThreadWorker); secondaryThread.Start(); } private void SecondaryThreadWorker() { TextValue = "thread text......."; } #region INotifyPropertyChanged Members protected void NotifyPropertyChanged(string propertyName) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } public event PropertyChangedEventHandler PropertyChanged; #endregion }
Then examining the cause, realized that the specific property raises an property changed notification . Immediately recalled the excellent article from Pete Brown in his 10rem.net blog.
The following implementation does the trick.
Snippet 2 (Just replace the INotifyPropertyChanged implementation)
#region INotifyPropertyChanged Members protected void NotifyPropertyChanged(string propertyName) { if (PropertyChanged != null) { if (Deployment.Current.Dispatcher.CheckAccess()) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } else { Deployment.Current.Dispatcher.BeginInvoke(() => { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); }); } } } public event PropertyChangedEventHandler PropertyChanged; #endregion
When I typed "Deployment.Current.Dispatcher.", it didn't show up the "CheckAccess()" method in the intellisense. But I verified it in the object which shows the existence of the method. So I manually typed the "CheckAccess()" method name and got complied without error.
References
http://10rem.net/blog/2012/01/10/threading-considerations-for-binding-and-change-notification-in-silverlight-5