メソッドSystem.Windows.Forms.Control.Invoke(Delegate method)を取得します
なぜこれがコンパイル時エラーを与えるのですか:
string str = "woop";
Invoke(() => this.Text = str);
// Error: Cannot convert lambda expression to type 'System.Delegate'
// because it is not a delegate type
しかし、これはうまくいきます:
string str = "woop";
Invoke((Action)(() => this.Text = str));
メソッドがプレーンなデリゲートを期待するのはいつですか?
ラムダ式は、デリゲート型または式ツリーに変換できますが、whichデリゲート型を知っている必要があります。署名を知るだけでは十分ではありません。たとえば、私が持っていると仮定します:
public delegate void Action1();
public delegate void Action2();
...
Delegate x = () => Console.WriteLine("hi");
x
によって参照されるオブジェクトの具体的なタイプはどうなると思いますか?はい、コンパイラcouldは適切な署名を持つ新しいデリゲート型を生成しますが、それはめったに役に立たず、エラーチェックの機会が少なくなります。
簡単に呼び出したい場合はControl.Invoke
でAction
を使用する最も簡単な方法は、拡張メソッドをControlに追加することです。
public static void Invoke(this Control control, Action action)
{
control.Invoke((Delegate) action);
}
ラムダを何度もキャストするのにうんざりしていませんか?
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());
}
}
ユーザーがUIスレッドにマーシャリングしようとしているため、これを取得するのは10分の9です。怠zyな方法は次のとおりです。
static void UI(Action action)
{
System.Windows.Threading.Dispatcher.CurrentDispatcher.BeginInvoke(action);
}
入力されたので、問題はなくなり(qv Skeetの答え)、この非常に簡潔な構文ができました。
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);
});
}
ボーナスポイントについては、別のヒントがあります。 UIの場合はこれを行いませんが、SomeMethodが完了するまでブロックする必要がある場合(要求/応答I/O、応答を待つなど)は、 WaitHandle (qv msdn WaitAll、 WaitAny、WaitOne)。
AutoResetEventはWaitHandleの派生物であることに注意してください。
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
}
そして、物事が絡まる可能性があるため、最後のヒント:WaitHandlesがスレッドを停止させます。これが彼らのやるべきことです。 UIスレッドをストール状態にマーシャリングしようとすると、アプリがハングします。この場合、(a)いくつかの深刻なリファクタリングが適切に行われ、(b)一時的なハックとして、次のように待つことができます。
bool wait = true;
ThreadPool.QueueUserWorkItem ((state) =>
{
//do asynch stuff
wait = false;
});
while (wait) Thread.Sleep(100);
ピーター・ウォン。あなたはダマンです。あなたのコンセプトをもう少し進めて、これら2つの機能を思いつきました。
private void UIA(Action action) {this.Invoke(action);}
private T UIF<T>(Func<T> func) {return (T)this.Invoke(func);}
これら2つの関数をフォームアプリに配置し、このようなバックグラウンドワーカーから呼び出しを行うことができます
int row = 5;
string ip = UIF<string>(() => this.GetIp(row));
bool r = GoPingIt(ip);
UIA(() => this.SetPing(i, r));
少し怠け者かもしれませんが、ワーカーが実行する機能をセットアップする必要はありません。これは、このような場合に非常に便利です。
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));
}
基本的に、gui DataGridViewからIPアドレスを取得し、それらをpingし、結果のアイコンを緑または赤に設定し、フォーム上のボタンを再度有効にします。はい、それはバックグラウンドワーカーの「parallel.for」です。はい、それは多くのオーバーヘッドを呼び出しますが、短いリスト、およびよりコンパクトなコードでは無視できます。
@ Andrey Naumov の答えに基づいてこれを構築しようとしました。これはわずかな改善かもしれません。
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;
}
}
ここで、型パラメーターS
は仮パラメーター(残りの型を推測するために最低限必要な入力パラメーター)です。次のように呼び出すことができます:
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!");
同じクラスでAction<S>
とExpression<Action<S>>
に追加のオーバーロードを同様に追加できます。 otherビルトインデリゲートおよび式の種類では、Lambda
、Lambda<S, T>
、Lambda<S, T, U>
などの個別のクラスを記述する必要があります。
この利点は、元のアプローチよりも優れています。
型指定が1つ少なくなります(仮パラメーターのみを指定する必要があります)。
これは、例に示すように、T
がstring
であるときだけでなく、Func<int, T>
に対して使用する自由を与えます。
すぐに式をサポートします。以前のアプローチでは、次のようなタイプを再度指定する必要があります。
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!");
式のため。
他のデリゲート(および式)型のクラスを拡張することも、上記と同様に面倒です。
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());
私のアプローチでは、型を1回だけ宣言する必要があります(Func
sには1つ少なすぎます)。
Andreyの答えを実装するもう1つの方法は、完全に汎用的にならないようにすることです。
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;
}
したがって、物事は次のようになります:
var l = Lambda<int>.Expression;
var e1 = l(x => x.ToString());
var e2 = l(x => "Hello!");
var e3 = l(x => x + x);
それはさらに少ないタイピングですが、特定のタイプセーフティを失い、imo、これは価値がありません。
パーティーに少し遅れましたが、このようにキャストすることもできます
this.BeginInvoke((Action)delegate {
// do awesome stuff
});
XUnitと Fluent Assertions で遊ぶことで、このインライン機能を非常にクールな方法で使用することができました。
Before
[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");
}
After
[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.");
}
this.Dispatcher.Invoke((Action)(() => { textBox1.Text = "Test 123"; }));