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
