We Keep Coding

Passing Actions into generic functions

I'm trying to wrap my head around different concepts in Csharp by trying different things. A create a generic function that takes in an action. The action has one input parameter and returns void. I create a simple action that is linked to a lambda function (returns void has one parameter x). I am able to run the action but when I pass the function to my generic function I am not sure how to add the input parameter. act("Some Int") doesn't work.
How do I pass in a value to an action?
public MainWindow()
{
InitializeComponent();
Action<int> myAction = (x) => Console.WriteLine(x);
myAction(13);
test(myAction);
}
private static void test<T>(Action<T> act)
{
act(); // How do i pass in an int Here?
}

Simply calling act("Some Int") as you have just required the Action act to be a genric function. Therefore you cannot specifically invoke it with one fixed variable type. You can solve your problem by modifying the test-method
private static void test<T>(Action<T> act, T value)
{
act(value); // How do i pass in an int Here?
}
...
test(myAction,integerValue);
Now you can call the Action with a given intvalue.

I can see what you are trying to do, and just wanted to throw this pattern up, since we often do this when we have to use closures and the parameters could be wildly different.
In those cases, rather than define an Action<T> which kind of ties you down from being able to use closures, you would just simply define your method as Action. So test would look like this:
private static void test(Action act)
{
act(); // yup, that's all there is to it!
}
So how would you pass in the parameter(s)? Simple: use closures. Like this:
public MainWindow()
{
InitializeComponent();
var x = 13; // this defined outside now...
Action myAction = () => Console.WriteLine(x); // you're basically using the closure here.
myAction();
test(myAction);
}
We often use this sort of approach when we're context switching (aka thread jumping), and need the thread continuation to pick up one or more variable values at the point it executes. That's just one example, there's quite a few other valid use cases as well.
Your experimental example, if I'm reading it correctly, could also qualify as a situation where closures could be a good fit.

Passing statement lambda as parameter

After following this question on updating a GUI from another thread I wanted to extend the code slightly so that it worked for something other than property assignment. Specifically I was trying to find a way to assign some functionality directly to a lambda so that I can define the behavior as needed (I modified the original slightly for WPF):
private delegate void UpdateControlThreadSafeDelegate(Control control, System.Linq.Expressions.Expression<Action> property);
public void UpdateControl(Control control, System.Linq.Expressions.Expression<Action> property)
{
// If calling thread is not associated with control dispatcher, call our thread safe property update delegate
if (!control.Dispatcher.CheckAccess())
{
control.Dispatcher.Invoke(new UpdateControlThreadSafeDelegate(UpdateControl), new object[] { control, property });
}
else
{
Action call = property.Compile();
call();
}
}
With usage:
UpdateControl(lbFoo, () => lbFoo.Items.Clear()); // where lbFoo is a ListBox control
This works fine. But I'd rather allow do something like:
UpdateControl(lbFoo, () => { lbFoo.Items.Clear(); lbFoo.Items.Add("Bar");});
This does not work, returning error CS0834: A lambda expression with a statement body cannot be converted to an expression tree. The error is clear, I'm just not certain on how best to proceed. I could follow my original usage and do what I need in several lines, it's just not as tidy.
I'm guessing there is a better/easier way to do what I want.

If you don't use expressions, and just pass the action, like so:
public void UpdateControl(Control control, Action actionToExecute)
Then you can use this as written. The only other change will be your else statement, where you would just call this directly:
else
{
actionToExecute();
}

Help with understanding C# syntax while Invoking a new Action

I am new to c# and do not understand the syntax of invoking a new action or even what an action is. From my understanding in Port1_DataReceived, I have to create an action because I am in a new tread... Can anyone elaborate on why I need to do this?
public Form1()
{
InitializeComponent();
SerialPort Port1 = new SerialPort("COM11", 57600, Parity.None, 8, StopBits.One);
Port1.DataReceived += new SerialDataReceivedEventHandler(Port1_DataReceived);
Port1.Open();
}
private void Port1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
SerialPort Port = (SerialPort)sender;
string Line = "";
int BytestoRead = Port.BytesToRead;
Line = Port.ReadLine();
label1.Invoke(new Action(() =>
{
label1.Text = Line;
}));
}
The code snip that I am really having trouble understanding is:
label1.Invoke(new Action(() =>
{
label1.Text = Line;
}));
Can someone break down what this is doing.. I am sure it is nothing to complicated, just that I have never seen anything like it before. The syntax that is really holding me up is ()=> the new action is pointing to the code below or something??

This uses something known as a "lambda expression" to create an anonymous delegate that matches the signature expected by the Action constructor.
You could achieve the same effect like this:
label1.Invoke(SetText);
...
public void SetText() { label1.Text = Line; }
or like this:
label1.Invoke(new Action(SetText));
...
public void SetText() { label1.Text = Line; }
or like this:
label1.Invoke(new Action(delegate() { label1.Text = Line; }));
or like this:
label1.Invoke(delegate() { label1.Text = Line; });
or like this:
label1.Invoke(() => label1.Text = Line);
These are mostly just syntactic shortcuts to make it easier to represent an action.
Note that lambda expressions often have parameters. When there is only one parameter, the parentheses are optional:
list.ToDictionary(i => i.Key);
When there are no parameters or multiple parameters, the parentheses are necessary to make it obvious what you're doing. Hence, the () =>.

Let's break it down piece by piece.
label1.Invoke(
This is the Control.Invoke method. Here's how it's defined:
public Object Invoke(Delegate method);
Executes the specified delegate on the thread that owns the control's underlying window handle.
What that means is that you give it a reference to a method to call, and Control.Invoke will make sure it gets called on the UI thread (which will prevent cross-threading exceptions while updating the UI.) It takes a default Delegate as a parameter, which means you need to pass it a method that takes no parameters and has no return value. That's where the System.Action delegate type comes in:
public delegate void Action();
Using lambda expressions, we can create an Action delegate inline. First, we specify the delegate type:
label1.Invoke(new Action(
Then, we will begin the lambda syntax. An empty set of parenthesis will denote that the lambda function takes no parameters, and an "arrow" afterwards shows that we want to start the method:
label1.Invoke(new Action(() =>
Now, because the lambda method has no return value (but must execute a statement) we need to surround the code we want to execute on the UI thread in curly braces:
label1.Invoke(new Action(() =>
{
label1.Text = Line;
}
Close up the remaining parenthesis, and you have the full, finished statement.
label1.Invoke(new Action(() =>
{
label1.Text = Line;
}));

Generally when you want to add something to you GUI and you are working from another thread you need to do something called Invocation.
To make an invocation you use either a Controls Invoke method or the something like an Application Dispatcher, these methods generally take an Action. An Action is just what it sounds like, something that is to be performed.
In your case what you are doing is that you want to add a line of text to an element that lives on your GUI, so what you need to do is to create an Action ( anonymouse method ) and in this action you just say "Add this to my Control". And then you Invoke this to avoid cross-threading problems.
()=> is just a "shortcut"(lambda way) to create a method, that is anonymous. This means that you can't call this from anywhere but the context of where you created the anonymous method.
You can also Invoke a "global" method, it doesn't have to be an anonymous method.

An Action is a delegate type, in other words it encapsulates a function. Specifically an Action encapsulates a function that returns void, whereas for instance a Func would encapsulate a function with a return value. These are alot like a function pointers in C++ -- essentially a reference to a function ie a way to encapsulate behavior.
The .Invoke() method takes the Action delegate and runs the function it points to. In this case the function it points to is the lambda expression:
() => { label1.Text = Line }
The initial parentheses denote any parameters being passed into the function. In this case there are no parameters so the parentheses are empty. For example if you wanted to pass in two strings, you would do:
var action = new Action<string, string>( (x, y) => { // use x and y }
Whatever follows the '=>' expression is essentially the body of the function. You have access to the variables specified in the parentheses inside the scope of this body.
Altogether this is a quick way to create an anonymous function on the fly that essentially is equivalent to the following:
public void SetLine()
{
label1.Text = Line;
}
As such you could also create that Action object by doing:
var action = new Action(SetLine)
where you are passing in the name of the method to encapsulate instead of passing in a lambda. Whats passed in is known as a 'Method Group'.

Action is a delegate. Label1.Invoke() is being used to execute the code label1.Text = line to avoid Cross Threading Operation. the event handler for DataReceived event is executing on a different thread other than UI thread. label1.Invoke() will execute the code in UI thread.

This is generating an anonymous method (a lambda, precisely) and passing that to the invoke method. Lambdas are a great way to have code you only need once so you don't need a lot of helper methods doing one thing only.

This is ensuring that the label's text is running in the UI thread. The Port1_DataReceived event will likely run in a background thread, and the Label's text value should not be set from background threads. This prevents that from happening.

I don't know what the label1 is, but the could could be read as:
label1 is an Action, that recieves another action as parameter. It does something and when it calls action recieved in argument.
Now, I've read that and I could be a problem - label1 could not be an Action. As it is just a control which set here: label1.Text = Line;
You have an error in your app;
EDIT
Sorry, just read that:
http://msdn.microsoft.com/en-us/library/zyzhdc6b.aspx
Executes the specified delegate on the thread that owns the control's underlying window handle.
Code is correct.

What is the most direct way of transforming a lambda expression or anonymous function into a Delegate Object in C#?

I am writing some code to solve thread-safe issues in a system am working on, and one of the recommended approaches is to use delegates to solve cross-thread issues. But for some reason, I don't like having to define a delegate for every possible operation i might have to intercept, and thus prefer working with anonymous methods or lambda expressions, but I the compiler refuses to cast any of these to a System.Delegate object.
Is there a shortcut to this?
if (someListBox.InvokeRequired)
{
someListBox.Invoke(Some_System.Delegate_Object, new object[] {item});
}
else
someListBox.Items.Add(item);
I want something like...
if (someListBox.InvokeRequired)
{
someListBox.Invoke((i) => { someListBox.Items.Add(i); }, new object[] {item});
}
else
someListBox.Items.Add(item);

One of your problems is that the compiler can't infer the parameter types of your lamda. And even for a given parameter signature there are infinitely many potential delegate types. So you need to explicitly give a type. Action<...> and Func<...> are typical candidates if you don't care about parameter names.
I think this should work:
`someListBox.Invoke((Action<int>)((i) => {listviewResults.Items.Add(i); }), new object[] {item});`
Or in refactored form to avoid repeating yourself:
Action<int> myAction=(i) => listviewResults.Items.Add(i);
if (someListBox.InvokeRequired)
{
someListBox.Invoke( myAction, new object[] {item});
}
else
myAction(item);
And I see no reason why you'd want to have i as a parameter at all:
Action myAction = () => listviewResults.Items.Add(item);
if (someListBox.InvokeRequired)
{
someListBox.Invoke( myAction );
}
else
myAction();

The downside with the approach that you want is that the actual work will be implemented in two places. One alternative approach might look like this:
private void AddItemToListView(ListViewItem item, ListView listView)
{
if (listView.InvokeRequired)
{
listView.BeginInvoke((Action)delegate { AddItemToListView(item, listView); });
}
else
{
listView.Items.Add(item);
}
}
Then again, you could debate how often this code is executed. If it is not extremely much, perhaps its better to simplify it a bit by not checking for InvokeRequired, but rather always wrap the call in a delegate passed to BeginInvoke:
private void AddItemToListView(ListViewItem item, ListView listView)
{
listView.BeginInvoke((Action)delegate { listView.Items.Add(item); });
}

MethodInvoker vs Action for Control.BeginInvoke

Which is more correct and why?
Control.BeginInvoke(new Action(DoSomething), null);
private void DoSomething()
{
MessageBox.Show("What a great post");
}
or
Control.BeginInvoke((MethodInvoker) delegate {
MessageBox.Show("What a great post");
});
I kinda feel like I am doing the same thing, so when is the right time to use MethodInvoker vs Action, or even writing a lambda expression?
EDIT: I know that there isn't really much of a difference between writing a lambda vs Action, but MethodInvoker seems to be made for a specific purpose. Is it doing anything different?

Both are equally correct, but the documentation for Control.Invoke states that:
The delegate can be an instance of
EventHandler, in which case the sender
parameter will contain this control,
and the event parameter will contain
EventArgs.Empty. The delegate can also
be an instance of MethodInvoker, or
any other delegate that takes a void
parameter list. A call to an
EventHandler or MethodInvoker delegate
will be faster than a call to another
type of delegate.
So MethodInvoker would be a more efficient choice.

For each solution bellow I run a 131072 (128*1024) iterations (in one separated thread).
The VS2010 performance assistant give this results:
read-only MethodInvoker: 5664.53 (+0%)
New MethodInvoker: 5828.31 (+2.89%)
function cast in MethodInvoker: 5857.07 (+3.40%)
read-only Action: 6467.33 (+14.17%)
New Action: 6829.07 (+20.56%)
Call to a new Action at each iteration
private void SetVisibleByNewAction()
{
if (InvokeRequired)
{
Invoke(new Action(SetVisibleByNewAction));
}
else
{
Visible = true;
}
}
Call to a read-only, build in constructor, Action at each iteration
// private readonly Action _actionSetVisibleByAction
// _actionSetVisibleByAction= SetVisibleByAction;
private void SetVisibleByAction()
{
if (InvokeRequired)
{
Invoke(_actionSetVisibleByAction);
}
else
{
Visible = true;
}
}
Call to a new MethodInvoker at each iteration.
private void SetVisibleByNewMethodInvoker()
{
if (InvokeRequired)
{
Invoke(new MethodInvoker(SetVisibleByNewMethodInvoker));
}
else
{
Visible = true;
}
}
Call to a read-only, build in constructor, MethodInvoker at each iteration
// private readonly MethodInvoker _methodInvokerSetVisibleByMethodInvoker
// _methodInvokerSetVisibleByMethodInvoker = SetVisibleByMethodInvoker;
private void SetVisibleByMethodInvoker()
{
if (InvokeRequired)
{
Invoke(_methodInvokerSetVisibleByMethodInvoker);
}
else
{
Visible = true;
}
}
Call to the function cast in MethodInvoker at each iteration
private void SetVisibleByDelegate()
{
if (InvokeRequired)
{
Invoke((MethodInvoker) SetVisibleByDelegate);
}
else
{
Visible = true;
}
}
Example of call for the "New Action" solution :
private void ButtonNewActionOnClick(object sender, EventArgs e)
{
new Thread(TestNewAction).Start();
}
private void TestNewAction()
{
var watch = Stopwatch.StartNew();
for (var i = 0; i < COUNT; i++)
{
SetVisibleByNewAction();
}
watch.Stop();
Append("New Action: " + watch.ElapsedMilliseconds + "ms");
}

I prefer using lambdas and Actions/Funcs:
Control.BeginInvoke(new Action(() => MessageBox.Show("What a great post")));

Action is defined in System, while MethodInvoker is defined in System.Windows.Forms - you may be better off using Action, since it is portable to other places. You will also find more places that accept Action as a parameter than MethodInvoker.
However, the documentation does indicate that calls to delegates of type EventHandler or MethodInvoker in Control.Invoke() will be faster than any other type.
Aside from which namepsace they are in, I don't believe there is a meaningful functional difference between Action and MethodInvoker - they are essentially both defined as:
public delegate void NoParamMethod();
As an aside, Action has several overloads which allow parameters to be passed in - and it is generic so that they can be typesafe.

Also per MSDN:
MethodInvoker provides a simple delegate that is used to invoke a method with a void parameter list. This delegate can be used when making calls to a control's Invoke method, or when you need a simple delegate but do not want to define one yourself.
an Action on the other hand can take up to 4 parameters.
But I don't think there is any difference between MethodInvoker and Action as they both simply encapsulate a delegate that doesn't take a paremter and returns void
If you look at their definitions you'll simply see this.
public delegate void MethodInvoker();
public delegate void Action();
btw you could also write your second line as.
Control.BeginInvoke(new MethodInvoker(DoSomething), null);

It is a matter of preference in most cases, unless you intend to reuse the DoSomething() method. Also the anonymous functions will place your scoped variables on the heap, might make it a more expensive function.

Don't forget to somehow check if control is available at the moment, to avoid errors at closing form.
if(control.IsHandleCreated)
control.BeginInvoke((MethodInvoker)(() => control.Text="check123"));