Automatización del patrón de código solicitado

Podrías escribir un método de extensión:

public static void InvokeIfRequired(this Control c, Action<Control> action)
{
    if(c.InvokeRequired)
    {
        c.Invoke(new Action(() => action(c)));
    }
    else
    {
        action(c);
    }
}

Y úsalo así:

object1.InvokeIfRequired(c => { c.Visible = true; });

EDITAR: Como Simpzon señala en los comentarios, también puede cambiar la firma a:

public static void InvokeIfRequired<T>(this T c, Action<T> action) 
    where T : Control

Aquí está el formulario que he estado usando en todo mi código.

private void DoGUISwitch()
{ 
    Invoke( ( MethodInvoker ) delegate {
        object1.Visible = true;
        object2.Visible = false;
    });
} 

He basado esto en la entrada del blog aquí. No he tenido este enfoque fallarme, así que no veo ninguna razón para complicar mi código con una comprobación de la propiedad InvokeRequired.

Espero que esto ayude.

Crea un ThreadSafeInvoke.archivo de fragmento, y luego solo puede seleccionar las instrucciones de actualización, haga clic derecho y seleccione ' Envolvente con..."o Ctrl-K+S:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <Title>ThreadsafeInvoke</Title>
    <Shortcut></Shortcut>
    <Description>Wraps code in an anonymous method passed to Invoke for Thread safety.</Description>
    <SnippetTypes>
      <SnippetType>SurroundsWith</SnippetType>
    </SnippetTypes>
  </Header>
  <Snippet>
    <Code Language="CSharp">
      <![CDATA[
      Invoke( (MethodInvoker) delegate
      {
          $selected$
      });      
      ]]>
    </Code>
  </Snippet>
</CodeSnippet>

Aquí hay una versión mejorada/combinada de las respuestas de Lee, Oliver y Stephan.

public delegate void InvokeIfRequiredDelegate<T>(T obj)
    where T : ISynchronizeInvoke;

public static void InvokeIfRequired<T>(this T obj, InvokeIfRequiredDelegate<T> action)
    where T : ISynchronizeInvoke
{
    if (obj.InvokeRequired)
    {
        obj.Invoke(action, new object[] { obj });
    }
    else
    {
        action(obj);
    }
} 

La plantilla permite un código flexible y sin cast que es mucho más legible, mientras que el delegado dedicado proporciona eficiencia.

progressBar1.InvokeIfRequired(o => 
{
    o.Style = ProgressBarStyle.Marquee;
    o.MarqueeAnimationSpeed = 40;
});

Prefiero usar una sola instancia de un delegado de método en lugar de crear una nueva instancia cada vez. En mi caso, solía mostrar mensajes de progreso y (info / error) de un Backroundworker copiando y emitiendo grandes datos desde una instancia sql. Everywhile después de cerca de 70000 llamadas de progreso y mensajes mi formulario dejó de funcionar y mostrar nuevos mensajes. Esto no ocurrió cuando empecé a usar un único delegado de instancia global.

delegate void ShowMessageCallback(string message);

private void Form1_Load(object sender, EventArgs e)
{
    ShowMessageCallback showMessageDelegate = new ShowMessageCallback(ShowMessage);
}

private void ShowMessage(string message)
{
    if (this.InvokeRequired)
        this.Invoke(showMessageDelegate, message);
    else
        labelMessage.Text = message;           
}

void Message_OnMessage(object sender, Utilities.Message.MessageEventArgs e)
{
    ShowMessage(e.Message);
}

Uso:

control.InvokeIfRequired(c => c.Visible = false);

return control.InvokeIfRequired(c => {
    c.Visible = value

    return c.Visible;
});

Código:

using System;
using System.ComponentModel;

namespace Extensions
{
    public static class SynchronizeInvokeExtensions
    {
        public static void InvokeIfRequired<T>(this T obj, Action<T> action)
            where T : ISynchronizeInvoke
        {
            if (obj.InvokeRequired)
            {
                obj.Invoke(action, new object[] { obj });
            }
            else
            {
                action(obj);
            }
        }

        public static TOut InvokeIfRequired<TIn, TOut>(this TIn obj, Func<TIn, TOut> func) 
            where TIn : ISynchronizeInvoke
        {
            return obj.InvokeRequired
                ? (TOut)obj.Invoke(func, new object[] { obj })
                : func(obj);
        }
    }
}

Me gusta hacerlo un poco diferente, me gusta llamar "a mí mismo" si es necesario con una Acción,

    private void AddRowToListView(ScannerRow row, bool suspend)
    {
        if (IsFormClosing)
            return;

        if (this.InvokeRequired)
        {
            var A = new Action(() => AddRowToListView(row, suspend));
            this.Invoke(A);
            return;
        }
         //as of here the Code is thread-safe

Este es un patrón útil, el IsFormClosing es un campo que establezco en True cuando cierro mi formulario, ya que podría haber algunos subprocesos en segundo plano que aún se están ejecutando...

Nunca deberías escribir código que se vea así:

private void DoGUISwitch() {
    if (object1.InvokeRequired) {
        object1.Invoke(new MethodInvoker(() => { DoGUISwitch(); }));
    } else {
        object1.Visible = true;
        object2.Visible = false;
    }
}

Si tiene un código que se parece a este, entonces su aplicación no es segura para subprocesos. Significa que tienes código que ya está llamando a DoGUISwitch () desde un hilo diferente. Es demasiado tarde para estar comprobando si está en un hilo diferente. InvokeRequire debe ser llamado ANTES de hacer una llamada a DoGUISwitch. No debes acceder a ningún método o propiedad desde un hilo diferente.

Referencia: Control.Propiedad InvokeRequired donde se puede leer lo siguiente:

Además de la propiedad InvokeRequired, hay cuatro métodos en un control que es seguro llamar a subprocesos: Invoke, BeginInvoke, EndInvoke y CreateGraphics si la manija para el control ha sido ya crear.

En una arquitectura de CPU única no hay problema, pero en una arquitectura de CPU múltiple puede hacer que parte del subproceso de interfaz de usuario se asigne al procesador donde el el código de llamada se estaba ejecutando...y si ese procesador es diferente de donde se estaba ejecutando el subproceso de interfaz de usuario, cuando finalice el subproceso de llamada, Windows pensará que el subproceso de interfaz de usuario ha terminado y matará el proceso de aplicación, es decir, su aplicación saldrá sin error.