Pregunta

Encuentro que el modelo de eventos de .NET es tal que a menudo genero un evento en un hilo y lo escucho en otro hilo.Me preguntaba cuál es la forma más limpia de organizar un evento desde un hilo en segundo plano en mi hilo de interfaz de usuario.

Según las sugerencias de la comunidad, he usado esto:

// earlier in the code
mCoolObject.CoolEvent+= 
           new CoolObjectEventHandler(mCoolObject_CoolEvent);
// then
private void mCoolObject_CoolEvent(object sender, CoolObjectEventArgs args)
{
    if (InvokeRequired)
    {
        CoolObjectEventHandler cb =
            new CoolObjectEventHandler(
                mCoolObject_CoolEvent);
        Invoke(cb, new object[] { sender, args });
        return;
    }
    // do the dirty work of my method here
}
¿Fue útil?

Solución

Un par de observaciones:

  • No cree delegados simples explícitamente en un código como ese a menos que sea anterior a la versión 2.0, por lo que podría usar:
   BeginInvoke(new EventHandler<CoolObjectEventArgs>(mCoolObject_CoolEvent), 
               sender, 
               args);
  • Además, no necesita crear y completar la matriz de objetos porque el parámetro args es del tipo "params", por lo que puede simplemente pasar la lista.

  • probablemente favorecería Invoke encima BeginInvoke ya que esto último dará como resultado que el código se llame de forma asincrónica, lo que puede ser o no lo que busca, pero dificultaría la propagación del manejo de excepciones posteriores sin una llamada a EndInvoke.Lo que sucedería es que tu aplicación terminará obteniendo una TargetInvocationException en cambio.

Otros consejos

Tengo algún código para esto en línea.Es mucho mejor que las otras sugerencias;definitivamente compruébalo.

Uso de muestra:

private void mCoolObject_CoolEvent(object sender, CoolObjectEventArgs args)
{
    // You could use "() =>" in place of "delegate"; it's a style choice.
    this.Invoke(delegate
    {
        // Do the dirty work of my method here.
    });
}

Rechazo las declaraciones redundantes de delegados.

private void mCoolObject_CoolEvent(object sender, CoolObjectEventArgs args)
{
    if (InvokeRequired)
    {
        Invoke(new Action<object, CoolObjectEventArgs>(mCoolObject_CoolEvent), sender, args);
        return;
    }
    // do the dirty work of my method here
}

Para no eventos, puede utilizar el System.Windows.Forms.MethodInvoker delegar o System.Action.

EDITAR:Además, cada evento tiene su correspondiente EventHandler delegado por lo que no hay necesidad alguna de volver a declarar uno.

Hice la siguiente clase de llamada de subprocesos cruzados "universal" para mi propio propósito, pero creo que vale la pena compartirla:

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;

namespace CrossThreadCalls
{
  public static class clsCrossThreadCalls
  {
    private delegate void SetAnyPropertyCallBack(Control c, string Property, object Value);
    public static void SetAnyProperty(Control c, string Property, object Value)
    {
      if (c.GetType().GetProperty(Property) != null)
      {
        //The given property exists
        if (c.InvokeRequired)
        {
          SetAnyPropertyCallBack d = new SetAnyPropertyCallBack(SetAnyProperty);
          c.BeginInvoke(d, c, Property, Value);
        }
        else
        {
          c.GetType().GetProperty(Property).SetValue(c, Value, null);
        }
      }
    }

    private delegate void SetTextPropertyCallBack(Control c, string Value);
    public static void SetTextProperty(Control c, string Value)
    {
      if (c.InvokeRequired)
      {
        SetTextPropertyCallBack d = new SetTextPropertyCallBack(SetTextProperty);
        c.BeginInvoke(d, c, Value);
      }
      else
      {
        c.Text = Value;
      }
    }
  }

Y simplemente puedes usar SetAnyProperty() desde otro hilo:

CrossThreadCalls.clsCrossThreadCalls.SetAnyProperty(lb_Speed, "Text", KvaserCanReader.GetSpeed.ToString());

En este ejemplo, la clase KvaserCanReader anterior ejecuta su propio hilo y realiza una llamada para establecer la propiedad de texto de la etiqueta lb_Speed ​​en el formulario principal.

Creo que la forma más limpia es definitivamente para seguir la ruta AOP.Realice algunos aspectos, agregue los atributos necesarios y nunca más tendrá que volver a verificar la afinidad del hilo.

Utilice el contexto de sincronización si desea enviar un resultado al hilo de la interfaz de usuario.Necesitaba cambiar la prioridad del subproceso, así que dejé de usar subprocesos del grupo de subprocesos (código comentado) y creé un nuevo subproceso propio.Todavía pude usar el contexto de sincronización para determinar si la cancelación de la base de datos se realizó correctamente o no.

    #region SyncContextCancel

    private SynchronizationContext _syncContextCancel;

    /// <summary>
    /// Gets the synchronization context used for UI-related operations.
    /// </summary>
    /// <value>The synchronization context.</value>
    protected SynchronizationContext SyncContextCancel
    {
        get { return _syncContextCancel; }
    }

    #endregion //SyncContextCancel

    public void CancelCurrentDbCommand()
    {
        _syncContextCancel = SynchronizationContext.Current;

        //ThreadPool.QueueUserWorkItem(CancelWork, null);

        Thread worker = new Thread(new ThreadStart(CancelWork));
        worker.Priority = ThreadPriority.Highest;
        worker.Start();
    }

    SQLiteConnection _connection;
    private void CancelWork()//object state
    {
        bool success = false;

        try
        {
            if (_connection != null)
            {
                log.Debug("call cancel");
                _connection.Cancel();
                log.Debug("cancel complete");
                _connection.Close();
                log.Debug("close complete");
                success = true;
                log.Debug("long running query cancelled" + DateTime.Now.ToLongTimeString());
            }
        }
        catch (Exception ex)
        {
            log.Error(ex.Message, ex);
        }

        SyncContextCancel.Send(CancelCompleted, new object[] { success });
    }

    public void CancelCompleted(object state)
    {
        object[] args = (object[])state;
        bool success = (bool)args[0];

        if (success)
        {
            log.Debug("long running query cancelled" + DateTime.Now.ToLongTimeString());

        }
    }

Siempre me he preguntado qué tan costoso es siempre supongamos que se requiere la invocación...

private void OnCoolEvent(CoolObjectEventArgs e)
{
  BeginInvoke((o,e) => /*do work here*/,this, e);
}

Como nota al margen interesante, el enlace de WPF maneja la clasificación automáticamente para que pueda vincular la interfaz de usuario a las propiedades del objeto que se modifican en subprocesos en segundo plano sin tener que hacer nada especial.Esto ha demostrado ser un gran ahorro de tiempo para mí.

En XAML:

<TextBox Text="{Binding Path=Name}"/>

Puede intentar desarrollar algún tipo de componente genérico que acepte un Contexto de sincronización como entrada y la utiliza para invocar los eventos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top