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
 
No hay comentarios:
Publicar un comentario