INotifyPropertyChanged con hilos

Question

Tengo un

BindingList<T> 

que está unido a un DataGridView. Una propiedad en mi clase requiere mucho tiempo para calcular, así que enhebré la acción. Después del cálculo elevo el evento OnPropertyChanged() para notificar a la grilla que el valor está listo.

Al menos, esa es la teoría. Pero como el método OnPropertyChanged se llama desde un hilo diferente, obtengo algunas excepciones weired en el método OnRowPrePaint de la grilla.

¿Alguien puede decirme cómo preveo que el evento OnPropertyChanged se ejecute en el hilo principal? No puedo usar Form.Invoke, ya que la clase MyClass no sabe que se ejecuta en una aplicación Winforms.

public class MyClass : INotifyPropertyChanged 
{ 
    public int FastMember {get;set;} 

    private int? slowMember; 
    public SlowMember 
    { 
     get 
     { 
      if (slowMember.HasValue) 
       return slowMember.Value; 
      else 
      { 
       Thread t = new Thread(getSlowMember); 
       t.Start(); 
       return -1; 
      } 

     } 
    } 

    private void getSlowMember() 
    { 
     Thread.Sleep(1000); 
     slowMember = 5; 
     OnPropertyChanged("SlowMember"); 
    } 

    public event PropertyChangedEventHandler PropertyChanged; 
    private void OnPropertyChanged(string propertyName) 
    { 
     PropertyChangingEventHandler eh = PropertyChanging; 
     if (eh != null) 
     { 
      eh(this, e); 
     } 
    } 

} 

Answer 1

Por diseño, un control solo se puede actualizar por el hilo en el que se creó. Es por eso que está recibiendo excepciones.

Considere usar un BackgroundWorker y solo actualice el miembro después de que se haya completado la operación de larga duración mediante la suscripción de un manejador de eventos al RunWorkerCompleted.

Answer 2

Consideración 1:
Tome un vistazo a la clase UIThreadMarshal y su uso en este artículo:
UI Thread Marshaling in the Model Layer
Puede cambiar la clase de estático a instancia y lo inyecta en el objeto. Entonces su objeto no sabrá sobre la clase de Forma. Solo sabrá sobre la clase UIThreadMarshal.

Consideración 2:
No creo que devolver -1 desde su propiedad es una buena idea. Me parece un mal diseño.

Consideración 3:
Tal vez su clase no debería usar otro hilo. Tal vez sean las clases de consumidores las que decidan cómo llamar a su propiedad: directamente o en un hilo separado. En este caso, tal vez necesite proporcionar propiedades adicionales, como IsSlowMemberInitialized.

Answer 3

Aquí hay algo que escribí hace un tiempo; que debería funcionar razonablemente bien, pero tenga en cuenta el costo de un montón de actualizaciones ...

using System.ComponentModel; 
using System.Threading; 
public class ThreadedBindingList<T> : BindingList<T> { 
    SynchronizationContext ctx = SynchronizationContext.Current; 
    protected override void OnAddingNew(AddingNewEventArgs e) { 
     if (ctx == null) { BaseAddingNew(e); } 
     else { ctx.Send(delegate { BaseAddingNew(e); }, null); } 
    } 
    protected override void OnListChanged(ListChangedEventArgs e) { 
     if (ctx == null) { BaseListChanged(e); } 
     else { ctx.Send(delegate { BaseListChanged(e); }, null); } 
    } 
    void BaseListChanged(ListChangedEventArgs e) { base.OnListChanged(e); } 
    void BaseAddingNew(AddingNewEventArgs e) { base.OnAddingNew(e); } 
} 

Answer 4

La gente a veces se olvidan de que el controlador de eventos es un MultiCastDelegate y, como tal, tiene toda la información relativa a cada suscriptor que Debe manejar esta situación con elegancia sin imponer innecesariamente la penalización de rendimiento Invoke + Synchronization. He estado usando código como este para las edades:

using System.ComponentModel; 
// ... 

public event PropertyChangedEventHandler PropertyChanged; 

protected virtual void OnPropertyChanged(string propertyName) 
{ 
    var handler = PropertyChanged; 
    if (handler != null) 
    { 
     var e = new PropertyChangedEventArgs(propertyName); 
     foreach (EventHandler h in handler.GetInvocationList()) 
     { 
      var synch = h.Target as ISynchronizeInvoke; 
      if (synch != null && synch.InvokeRequired) 
       synch.Invoke(h, new object[] { this, e }); 
      else 
       h(this, e); 
     } 
    } 
} 

lo que hace es simple, pero recuerdo que casi me fracturé mi cerebro en ese entonces tratando de encontrar la mejor manera de hacerlo.

Primero "agarra" el controlador de eventos en una propiedad local para evitar cualquier condición de carrera.

Si el controlador no es nulo (al menos un suscriptor existe) prepara los argumentos del evento y luego recorre la lista de invocación de este delegado de multidifusión.

La lista de invocación tiene la propiedad de destino, que es el suscriptor del evento.Si este suscriptor implementa ISynchronizeInvoke (todos los controles de UI lo implementan), entonces revisamos su propiedad InvokeRequired, y es cierto que solo lo invocamos pasando el delegado y los parámetros. Llamarlo de esta manera sincronizará la llamada en el hilo de UI.

De lo contrario, simplemente llamamos directamente al delegado del controlador de eventos.