Warum muss ein Lambda-Ausdruck umgewandelt werden, wenn er als einfacher Delegate-Parameter angegeben wird?

Nehmen Sie die Methode System.Windows.Forms.Control.Invoke (Delegate-Methode)

Warum führt dies zu einem Fehler bei der Kompilierung:

string str = "woop";
Invoke(() => this.Text = str);
// Error: Cannot convert lambda expression to type 'System.Delegate'
// because it is not a delegate type

Dies funktioniert jedoch gut:

string str = "woop";
Invoke((Action)(() => this.Text = str));

Wann erwartet die Methode einen einfachen Delegaten?

Ein Lambda-Ausdruck kann entweder in einen Delegatentyp oder einen Ausdrucksbaum konvertiert werden - er muss jedoch wissen, welcher Delegattyp. Nur die Unterschrift zu kennen, reicht nicht aus. Angenommen, ich habe:

public delegate void Action1();
public delegate void Action2();

...

Delegate x = () => Console.WriteLine("hi");

Was würden Sie von dem konkreten Typ des Objekts erwarten, auf das Bezug genommen xwird? Ja, der Compiler könnte einen neuen Delegatentyp mit einer geeigneten Signatur generieren, aber das ist selten nützlich und Sie haben weniger Gelegenheit zur Fehlerprüfung.

Wenn Sie es einfach anrufen wollen Control.Invokemit einem Actionder einfachste Sache zu tun ist , eine Verlängerung Methode zur Steuerung hinzufügen:

public static void Invoke(this Control control, Action action)
{
    control.Invoke((Delegate) action);
}

Sind Sie es leid, immer wieder Lambdas zu werfen?

public sealed class Lambda<T>
{
    public static Func<T, T> Cast = x => x;
}

public class Example
{
    public void Run()
    {
        // Declare
        var c = Lambda<Func<int, string>>.Cast;
        // Use
        var f1 = c(x => x.ToString());
        var f2 = c(x => "Hello!");
        var f3 = c(x => (x + x).ToString());
    }
}

Neun Zehntel der Fälle erhalten die Benutzer dies, weil sie versuchen, auf dem UI-Thread zu marshallen. Hier ist der faule Weg:

static void UI(Action action) 
{ 
  System.Windows.Threading.Dispatcher.CurrentDispatcher.BeginInvoke(action); 
}

Jetzt, da es getippt ist, verschwindet das Problem (siehe Skeets Antwort) und wir haben diese sehr prägnante Syntax:

int foo = 5;
public void SomeMethod()
{
  var bar = "a string";
  UI(() =>
  {
    //lifting is marvellous, anything in scope where the lambda
    //expression is defined is available to the asynch code
    someTextBlock.Text = string.Format("{0} = {1}", foo, bar);        
  });
}

Für Bonuspunkte hier ein weiterer Tipp. Sie würden dies nicht für UI-Inhalte tun, aber in Fällen, in denen SomeMethod bis zum Abschluss blockiert werden muss (z. B. Anforderungs- / Antwort-E / A, Warten auf die Antwort), verwenden Sie ein WaitHandle (siehe msdn WaitAll, WaitAny, WaitOne).

Beachten Sie, dass AutoResetEvent eine WaitHandle-Ableitung ist.

public void BlockingMethod()
{
  AutoResetEvent are = new AutoResetEvent(false);
  ThreadPool.QueueUserWorkItem ((state) =>
  {
    //do asynch stuff        
    are.Set();
  });      
  are.WaitOne(); //don't exit till asynch stuff finishes
}

Und ein letzter Tipp, weil sich die Dinge verheddern können: WaitHandles blockieren den Faden. Das sollen sie tun. Wenn Sie versuchen, auf dem UI-Thread zu marshallen , während Sie ihn blockiert haben , bleibt Ihre App hängen. In diesem Fall (a) ist ein ernsthaftes Refactoring angebracht, und (b) als vorübergehender Hack können Sie folgendermaßen warten:

  bool wait = true;
  ThreadPool.QueueUserWorkItem ((state) =>
  {
    //do asynch stuff        
    wait = false;
  });
  while (wait) Thread.Sleep(100);

Peter Wone. Du bist ein Mann. Ich habe Ihr Konzept etwas weiterentwickelt und mir diese beiden Funktionen ausgedacht.

private void UIA(Action action) {this.Invoke(action);}
private T UIF<T>(Func<T> func) {return (T)this.Invoke(func);}

Ich platziere diese beiden Funktionen in meiner Formular-App und kann Anrufe von solchen Hintergrundmitarbeitern tätigen

int row = 5;
string ip = UIF<string>(() => this.GetIp(row));
bool r = GoPingIt(ip);
UIA(() => this.SetPing(i, r));

Vielleicht ein bisschen faul, aber ich muss keine Worker-Doed-Funktionen einrichten, was in solchen Fällen sehr praktisch ist

private void Ping_DoWork(object sender, System.ComponentModel.DoWorkEventArgs e)
{
  int count = this.dg.Rows.Count;
  System.Threading.Tasks.Parallel.For(0, count, i => 
  {
    string ip = UIF<string>(() => this.GetIp(i));
    bool r = GoPingIt(ip);
    UIA(() => this.SetPing(i, r));
  });
  UIA(() => SetAllControlsEnabled(true));
}

Rufen Sie im Wesentlichen einige IP-Adressen von einer GUI-DataGridView ab, pingen Sie sie an, setzen Sie die resultierenden Symbole auf Grün oder Rot und aktivieren Sie die Schaltflächen im Formular erneut. Ja, es ist ein "parallel.for" in einem Hintergrundarbeiter. Ja, es ist eine Menge Aufruf von Overhead, aber es ist vernachlässigbar für kurze Listen und viel kompakteren Code.

Ich habe versucht, dies auf der Antwort von @Andrey Naumov aufzubauen . Möglicherweise ist dies eine leichte Verbesserung.

public sealed class Lambda<S>
{
    public static Func<S, T> CreateFunc<T>(Func<S, T> func)
    {
        return func;
    }

    public static Expression<Func<S, T>> CreateExpression<T>(Expression<Func<S, T>> expression)
    {
        return expression;
    }

    public Func<S, T> Func<T>(Func<S, T> func)
    {
        return func;
    }

    public Expression<Func<S, T>> Expression<T>(Expression<Func<S, T>> expression)
    {
        return expression;
    }
}

Dabei Sist der Typparameter der formale Parameter (der Eingabeparameter, der mindestens erforderlich ist, um auf den Rest der Typen zu schließen). Jetzt können Sie es so nennen:

var l = new Lambda<int>();
var d1 = l.Func(x => x.ToString());
var e1 = l.Expression(x => "Hello!");
var d2 = l.Func(x => x + x);

//or if you have only one lambda, consider a static overload
var e2 = Lambda<int>.CreateExpression(x => "Hello!");

Sie können zusätzliche Überladungen für Action<S>und Expression<Action<S>>in derselben Klasse haben. Für andere in Delegaten und Ausdrucksarten gebaut, werden Sie separate Klassen gerne schreiben müssen Lambda, Lambda<S, T>,Lambda<S, T, U> usw.

Vorteil davon sehe ich gegenüber dem ursprünglichen Ansatz:

1. Eine Typspezifikation weniger (nur der formale Parameter muss angegeben werden).

2. Dies gibt Ihnen die Freiheit, es gegen jeden zu verwenden Func<int, T>, nicht nur wenn Tes gesagt wird string, wie in Beispielen gezeigt.

3. Unterstützt Ausdrücke sofort. Bei dem früheren Ansatz müssen Sie erneut Typen angeben, z.

   var e = Lambda<Expression<Func<int, string>>>.Cast(x => "Hello!");
   
   //or in case 'Cast' is an instance member on non-generic 'Lambda' class:
   var e = lambda.Cast<Expression<Func<int, string>>>(x => "Hello!");

   für Ausdrücke.

4. Das Erweitern der Klasse für andere Delegatentypen (und Ausdruckstypen) ist ähnlich umständlich wie oben.

   var e = Lambda<Action<int>>.Cast(x => x.ToString());
   
   //or for Expression<Action<T>> if 'Cast' is an instance member on non-generic 'Lambda' class:
   var e = lambda.Cast<Expression<Action<int>>>(x => x.ToString());

In meinem Ansatz müssen Sie Typen nur einmal deklarieren (das auch eins weniger für Funcs).

Eine andere Möglichkeit, Andreys Antwort umzusetzen, besteht darin, nicht vollständig generisch zu werden

public sealed class Lambda<T>
{
    public static Func<Func<T, object>, Func<T, object>> Func = x => x;
    public static Func<Expression<Func<T, object>>, Expression<Func<T, object>>> Expression = x => x;
}

Die Dinge reduzieren sich also auf:

var l = Lambda<int>.Expression;
var e1 = l(x => x.ToString());
var e2 = l(x => "Hello!");
var e3 = l(x => x + x);

Das ist noch weniger Tippen, aber Sie verlieren bestimmte Typensicherheit, und imo, das ist es nicht wert.

Etwas spät zur Party, aber du kannst auch so besetzen

this.BeginInvoke((Action)delegate {
    // do awesome stuff
});

 this.Dispatcher.Invoke((Action)(() => { textBox1.Text = "Test 123"; }));

Beim Spielen mit XUnit und Fluent Assertions war es möglich, diese Inline-Funktion auf eine Weise zu nutzen, die ich wirklich cool finde.

Vor

[Fact]
public void Pass_Open_Connection_Without_Provider()
{
    Action action = () => {
        using (var c = DbProviderFactories.GetFactory("MySql.Data.MySqlClient").CreateConnection())
        {
            c.ConnectionString = "<xxx>";
            c.Open();
        }
    };

    action.Should().Throw<Exception>().WithMessage("xxx");
}

Nach dem

[Fact]
public void Pass_Open_Connection_Without_Provider()
{
    ((Action)(() => {
        using (var c = DbProviderFactories.GetFactory("<provider>").CreateConnection())
        {
            c.ConnectionString = "<connection>";
            c.Open();
        }
    })).Should().Throw<Exception>().WithMessage("Unable to find the requested .Net Framework Data Provider.  It may not be installed.");
}