I'm trying to understand the difference between:
someObject.SomeEventName += OnEventHappend;
private void OnEventHappened(object sender, EventArgs e)
{
}
AND
someOBject.SomeEventName += ( o, e) => { };
Is there a difference and does it matter one way or the other.
The second is called a "lambda". It's a way of creating an anonymous function.
Other than the fact that the second function doesn't have a name, and thus can't be used anywhere else, while the first does have a name and could be used somewhere else, there aren't really any differences.
The compiler will end up creating a class and a method within that class to represent the lambda, so technically it will have a name, you just won't be allowed to use it in your code.
Probably the most significant point to note is that lambdas can close over variables. This is where the lambda body refers to a varaiable outside of it's own scope, i.e:
int value = 5;
someObject.SomeEvent += (s,e) => { Console.WriteLine(value);};
The same functionality can be accomplished using entirely named methods (after all the compiler will refactor that code into named methods/objects at some point) but the end result will be slightly more complex than just one new method in the class.
Well one obvious difference is that the later is an anonymous event handler implemented as a statment lambda, so you can't easily unsubscribe it at a later date. The advantage of it though is its succinctness.
Related
I am working with a WCF service, calls to the service are invoked using an async method. As I am working with Xamarin studio the WCF proxy must be created using the silverlight tools (slsvcutil.exe) and as such this seems to be the only way to achieve what I am doing.
To make a call to the service I must make a call like so:
Soap.client.DoActionCompleted += Soap_client_DoActionCompleted;
Soap.client.DoActionAsync(parameter);
And then declare the delegate for DoActionCompleted like so:
void Soap_client_DoActionCompleted(object sender, DoActionCompletedEventArgs e)
{
Soap.client.DoActionCompleted -= Soap_client_DoActionCompleted;
// Do stuff
}
I have to remove Soap_client_DoActionCompleted after the call to prevent it from stacking further calls on it later.
The problem is I have many calls like this in my code, and it is beginning to get very messy and hard to follow the logic when writing the code. I would much prefer to be able to declare the code inline so it's much easier to follow, something like this:
Soap.client.DoActionCompleted += (sender, e) =>
{
Soap.client.DoActionCompleted -= x;
// Do stuff
}
Soap.client.DoActionAsync(parameter);
In the above snippet, I'd like to be able to pass the delegate that it is inside to remove it then and there, but the problem is I have no idea if this is even possible.
While I know there are almost certainly better ways of doing the above, I'm a little trapped by the fact that I am required to use slsvcutil.exe to generate the proxy for the service, and writing the proxy manually isn't an option as the service gets regular updates.
It's kind of possible if you assign the lambda expression to a delegate variable first. It just won't be as nice as what you're hoping for.
And even then, to avoid a use of unassigned local variable compiler error, you have to first initialize the delegate variable to null before you can assign the lambda expression that will have a reference to itself.
So, using your example, it would look like this (I'm assuming the type of DoActionCompleted is EventHandler. Simply adjust if I'm wrong):
EventHandler eventHandler = null;
eventHandler = (sender, e) =>
{
Soap.client.DoActionCompleted -= eventHandler;
// do stuff
};
Soap.client.DoActionCompleted += eventHandler;
Soap.client.DoActionAsync(parameter);
It's up to you to decide if it's worth it for you to use this pattern.
For a simple example, if I had some sort of button UI class, could I write a function that takes an expression that points to its Click event handler:
SomeMethod<SomeButtonClass>(button => button.Click);
I'm trying to eliminate some magic strings currently being used for a system to make events awaitable. The code in question is derived from a blog post by Frank Krueger (a worthwhile read, if you want some background).
public static Task<TEventArgs> GetEventAsync<TEventArgs>(this object eventSource, string eventName) where TEventArgs : EventArgs {
//...
Type type = eventSource.GetType();
EventInfo ev = type.GetEvent(eventName);
//...
}
While the specifics inside probably aren't important, the full method allows you to use an Event triggering as the completion source for a Task, making it easier to manage with await. For some class that raises an event, you can tie into a Task based on that event with a simple call.
Task<EventArgs> eventTask = someEventCausingObject.GetEventAsync<EventArgs>("SomeEventHandler");
// traditionally used as someEventCausingObject.SomeEventHandler += ...;
await eventTask;
// Proceed back here when SomeEventHandler event is raised.
I have been using this happily for a couple projects, but it has its drawbacks, one of the biggest being the use of hard-coded event name strings. This makes event name changes turn into runtime exceptions, and determining usage of the event is difficult.
I started trying to make a version that would allow the EventHandler to be passed in as part of an Expression with the goal of something like this:
await someEventCausingObject.GetEventAsync<EventCausingClass, EventArgs>(x => x.SomeEventHandler);
...with the corresponding method signature...
public static Task<TEventArgs> GetEventAsync<TSource, TEventArgs>(this TSource eventSource, Expression<Func<TSource, EventHandler>> eventHandlerExpression) where TEventArgs : EventArgs {
//...
}
Unfortunately, the lambda expression in the calling code causes a compile error:
Error CS0070: The event `SomeEventHandler' can only appear on the left hand side of += or -= when used outside of the type `EventCausingClass'.
This makes some sense given how event handlers are typically used, but I was hoping to find a better solution going forward than the pre-specified string name. It seems searches for combinations of "expression" and "eventhandler" all tend to be polluted with people describing lambda expressions for beginning += event handler assignment. I'm hoping I am missing something obvious here.
No, it is not possible to target an event. Basically event is not a real type member, but just C# syntax which produces add_EventName and remove_EventName methods pair.
You could try refer to these internal methods name, but it's not possible in C# - http://msdn.microsoft.com/en-us/library/z47a7kdw.aspx
There are many similar questions in SO, with the same answer NO - like this one from Jon Skeet https://stackoverflow.com/a/4756021/2170171
If you're real crazy, you can try something like
private static void Subscribe(Action addHandler)
{
var IL = addHandler.Method.GetMethodBody().GetILAsByteArray();
// Magic here, in which we understand ClassName and EventName
???
}
with usage like
Subscribe(() => new Button().Click += null);
You could try using Cecil http://www.mono-project.com/Cecil for analyzing IL, or implement your own logic as it should not be too hard for predictable line of code.
I don't think that it is good solution though, as it just replaces one headache (proper event naming) with another one (proper Subscribe calling). Though, it will help with rename stuff.
I wrote extension method to Timer class to destroy it after certain amount of time. seems like it actually only set false in timer.enable fields but don't really set the whole things to false. Is there a way to nullify an object from it own extension method?
and another thing - is it good practice to implement it in that way or I should expect sync issues and more surprises?
timer.DestroyAfter(1.Hours()) :
public static void DestroyAfter(this Timer timer, TimeSpan timeSpan)
{
var killingTimer = new Timer(timeSpan.TotalMilliseconds)
{
AutoReset = false,
};
killingTimer.Elapsed += (sender, e) =>
{
timer.Stop();
**timer = null;** //doesn't seem to work though line is executed
killingTimer.Stop();
killingTimer = null;
};
killingTimer.Start();
}
This would only be possible if the "this" parameter was also a ref parameter, which it is not.
So the answer is no (in the current C# implementation)
Regarding your other question: there's nothing wrong with the way you implemented it (stopping the timer and clearing the reference to the captured "killingTimer" variable).
There is nothing special about extensions methods. What the this modifier says it that call like timer.DestroyAfter(time) should be compiled as if you wrote DestroyAfter(timer, time).
And in normal methods, change to the parameter variable doesn't affect the original variable. In normal methods, there is a way to achieve that: use ref parameter. But you can't do that with the this parameter of an extension method.
Besides, this would be very confusing: If I write timer.DestroyAfter(time), then suddenly some time in the future, timer becomes null? I certainly would not expect that.
I've read two books, tons of examples. They still make next to no sense to me. I could probably write some code that uses delegates, but I have no idea why. Am I the only one with this problem, or am I just an idiot? If anyone can actually explain to me when, where, and why I would actually use a delegate, I'll love you forever.
Delegates are just a way to pass around a function in a variable.
You pass a delegated function to do a callback. Such as when doing asynchronous IO, you pass a delegated function (a function you have written with the delegate parameter) that will be called when the data has been read off the disk.
As other people have mentioned delegates are handy for callbacks. They're useful for a whole load of other things too. For example in a game I've been working on recently bullets do different things when they hit (some do damage, some actually increase the health of the person they hit, some do no damage but poison the target and so on). The classical OOP way to do this would be a base bullet class and a load of subclasses
Bullet
DamageBullet
HealBullet
PoisonBullet
DoSomethingElseBullet
PoisonAndThenHealBullet
FooAndBarBullet
....
With this pattern, I have to define a new subclass every time I want some new behavior in a bullet, which is a mess and leads to a lot of duplicated code. Instead I solved it with delegates. A bullet has an OnHit delegate, which is called when the bullet hits an object, and of course I can make that delegate anything I like. So now I can create bullets like this
new Bullet(DamageDelegate)
Which obviously is a much nicer way of doing things.
In functional languages, you tend to see a lot more of this kind of thing.
A delegate is a simple container that knows where in the machine's memory a specific method is located.
All delegates have an Invoke(...) method, thus when someone has a delegate, he can actually execute it, without really having to know or bother what that method actually does.
This is especially helpful for decoupling stuff. GUI frameworks wouldn't be possible without that concept, because a Button simply can't know anything about your program you're going to use it in, so it can't call your methods by itself whenever it is clicked. Instead, you must tell it which methods it should call when it is clicked.
I guess you're familiar with events and you do use them regularly. An event field is actually a list of such delegates (also called a multi-cast delegate). Maybe things will become clearer when we look at how we could "simulate" events in C# if it didn't have the event keyword, but only (non-multicast) delegates:
public class Button : Rectangle
{
private List<Delegate> _delegatesToNotifyForClick = new List<Delegate>();
public void PleaseNotifyMeWhenClicked(Delegate d)
{
this._delegatesToNotifyForClick.Add(d);
}
// ...
protected void GuiEngineToldMeSomeoneClickedMouseButtonInsideOfMyRectangle()
{
foreach (Delegate d in this._delegatesToNotifyForClick)
{
d.Invoke(this, this._someArgument);
}
}
}
// Then use that button in your form
public class MyForm : Form
{
public MyForm()
{
Button myButton = new Button();
myButton.PleaseNotifyMeWhenClicked(new Delegate(this.ShowMessage));
}
private void ShowMessage()
{
MessageBox.Show("I know that the button was clicked! :))))");
}
}
Hope I could help a little. ;-)
Maybe this helps:
A delegate is a type (defining a method signature)
A delegate instance is a reference to a method (AKA function pointer)
A callback is a parameter of a delegate-type
An event is a (kind of) property of a delegate-type
The purpose of delegates is that you can have variables/fields/parameters/properties(events) that 'hold' a function. That lets you store/pass a specific function you select runtime. Without it, every function call has to be fixed at compile time.
The syntax involving delegates (or events) can be a bit daunting at first, this has 2 reasons:
simple pointer-to-functions like in C/C++ would not be type-safe, in .NET the compiler actually generates a class around it, and then tries to hide that as much as possible.
delegates are the corner-stone of LINQ, and there is a steep evolution from the specify-everything in C#1 through anonymous methods (C#2) to lambdas (C#3).
Just get acquainted with 1 or 2 standard patterns.
Come on Guys! All of you successfully complicated the DELEGATES :)!
I will try to leave a hint here : i understood delegates once I realized jquery ajax calls in Javascript. for ex: ajax.send(url, data, successcallback, failcallback) is the signature of the function. as you know, it sends data to the server URL, as a response, It might be 200OK or some other error. In case of any such event(success/fail), you want to execute a function. So, this acts like a placeholder of a function, to be able to mention in either success or failure.
That placeholder may not be very generic - it might accept a set of parameters and may/may not return value. That declaration of such Placeholder, if done in C# IS CALLED DELEGATE! As javascript functions not strict with number of arguments, you would just see them as GENERIC placeholders...but C# has some STRICT declarations... that boils down to DELEGATE declarations!!
Hope it helps!
Delegate is a type safe function pointer, meaning delegate points to a function when you invoke the delegate function the actual function will be invoked. It is mainly used when developing core application framework. When we want to decouple logic then we can use delegate. Ie instead of hand coding logic in a particular method we can pass the delegate to the function and set different function logic inside the delegate function. Delegates adds flexibility to your framework.
Example: how to use it
class Program
{
public static void Main()
{
List<Employee> empList = new List<Employee>() {
new Employee () {Name = "Test1", Experience = 6 },
new Employee () {Name = "Test2", Experience = 2 },
};
// delegate point to the actual function
IsPromotable isEligibleToPromote = new IsPromotable(IsEligibleToPromoteEmployee);
Employee emp = new Employee();
// pass the delegate to a method where the delegate will be invoked.
emp.PromoteEmployee(empList, isEligibleToPromote);
// same can be achieved using lambda empression no need to declare delegate
emp.PromoteEmployee(empList, emply => emply.Experience > 2);
Console.ReadKey();
}
// this condition can change at calling end
public static bool IsEligibleToPromoteEmployee(Employee emp)
{
if (emp.Experience > 5)
return true;
else
return false;
}
}
public delegate bool IsPromotable(Employee emp);
public class Employee
{
public string Name { get; set; }
public int Experience { get; set; }
// conditions changes it can 5, 6 years to promote
public void PromoteEmployee(List<Employee> employees, IsPromotable isEligibleToPromote)
{
foreach (var employee in employees)
{
// invoke actual function
if (isEligibleToPromote(employee))
{
Console.WriteLine("Promoted");
}
}
}
}
Is there any different between declaring event Action<> and event EventHandler<>.
Assuming it doesn't matter what object actually raised an event.
for example:
public event Action<bool, int, Blah> DiagnosticsEvent;
vs
public event EventHandler<DiagnosticsArgs> DiagnosticsEvent;
class DiagnosticsArgs : EventArgs
{
public DiagnosticsArgs(bool b, int i, Blah bl)
{...}
...
}
usage would be almost the same in both cases:
obj.DiagnosticsEvent += HandleDiagnosticsEvent;
There are several things that I don’t like about event EventHandler<> pattern:
Extra type declaration derived from
EventArgs
Compulsory passing of object source –
often no one cares
More code means more code to maintain without any clear advantage.
As a result, I prefer event Action<>
However, only if there are too many type arguments in Action<>, then an extra class would be required.
Based on some of the previous answers, I'm going to break my answer down into three areas.
First, physical limitations of using Action<T1, T2, T2... > vs using a derived class of EventArgs. There are three: First, if you change the number or types of parameters, every method that subscribes to will have to be changed to conform to the new pattern. If this is a public facing event that 3rd party assemblies will be using, and there is any possiblity that the event args would change, this would be a reason to use a custom class derived from event args for consistencies sake (remember, you COULD still use an Action<MyCustomClass>) Second, using Action<T1, T2, T2... > will prevent you from passing feedback BACK to the calling method unless you have a some kind of object (with a Handled property for instance) that is passed along with the Action. Third, you don't get named parameters, so if you're passing 3 bool's an int, two string's, and a DateTime, you have no idea what the meaning of those values are. As a side note, you can still have a "Fire this event safely method while still using Action<T1, T2, T2... >".
Secondly, consistency implications. If you have a large system you're already working with, it's nearly always better to follow the way the rest of the system is designed unless you have an very good reason not too. If you have publicly facing events that need to be maintained, the ability to substitute derived classes can be important. Keep that in mind.
Thirdly, real life practice, I personally find that I tend to create a lot of one off events for things like property changes that I need to interact with (Particularly when doing MVVM with view models that interact with each other) or where the event has a single parameter. Most of the time these events take on the form of public event Action<[classtype], bool> [PropertyName]Changed; or public event Action SomethingHappened;. In these cases, there are two benefits. First, I get a type for the issuing class. If MyClass declares and is the only class firing the event, I get an explicit instance of MyClass to work with in the event handler. Secondly, for simple events such as property change events, the meaning of the parameters is obvious and stated in the name of the event handler and I don't have to create a myriad of classes for these kinds of events.
The main difference will be that if you use Action<> your event will not follow the design pattern of virtually any other event in the system, which I would consider a drawback.
One upside with the dominating design pattern (apart from the power of sameness) is that you can extend the EventArgs object with new properties without altering the signature of the event. This would still be possible if you used Action<SomeClassWithProperties>, but I don't really see the point with not using the regular approach in that case.
The advantage of a wordier approach comes when your code is inside a 300,000 line project.
Using the action, as you have, there is no way to tell me what bool, int, and Blah are. If your action passed an object that defined the parameters then ok.
Using an EventHandler that wanted an EventArgs and if you would complete your DiagnosticsArgs example with getters for the properties that commented their purpose then you application would be more understandable. Also, please comment or fully name the arguments in the DiagnosticsArgs constructor.
I realize that this question is over 10 years old, but it appears to me that not only has the most obvious answer not been addressed, but that maybe its not really clear from the question a good understanding of what goes on under the covers. In addition, there are other questions about late binding and what that means with regards to delegates and lambdas (more on that later).
First to address the 800 lb elephant/gorilla in the room, when to choose event vs Action<T>/Func<T>:
Use a lambda to execute one statement or method. Use event when you
want more of a pub/sub model with multiple
statements/lambdas/functions that will execute (this is a major
difference right off the bat).
Use a lambda when you want to compile statements/functions to expression trees. Use delegates/events when you want to participate in more traditional late binding such as used in reflection and COM interop.
As an example of an event, lets wire up a simple and 'standard' set of events using a small console application as follows:
public delegate void FireEvent(int num);
public delegate void FireNiceEvent(object sender, SomeStandardArgs args);
public class SomeStandardArgs : EventArgs
{
public SomeStandardArgs(string id)
{
ID = id;
}
public string ID { get; set; }
}
class Program
{
public static event FireEvent OnFireEvent;
public static event FireNiceEvent OnFireNiceEvent;
static void Main(string[] args)
{
OnFireEvent += SomeSimpleEvent1;
OnFireEvent += SomeSimpleEvent2;
OnFireNiceEvent += SomeStandardEvent1;
OnFireNiceEvent += SomeStandardEvent2;
Console.WriteLine("Firing events.....");
OnFireEvent?.Invoke(3);
OnFireNiceEvent?.Invoke(null, new SomeStandardArgs("Fred"));
//Console.WriteLine($"{HeightSensorTypes.Keyence_IL030}:{(int)HeightSensorTypes.Keyence_IL030}");
Console.ReadLine();
}
private static void SomeSimpleEvent1(int num)
{
Console.WriteLine($"{nameof(SomeSimpleEvent1)}:{num}");
}
private static void SomeSimpleEvent2(int num)
{
Console.WriteLine($"{nameof(SomeSimpleEvent2)}:{num}");
}
private static void SomeStandardEvent1(object sender, SomeStandardArgs args)
{
Console.WriteLine($"{nameof(SomeStandardEvent1)}:{args.ID}");
}
private static void SomeStandardEvent2(object sender, SomeStandardArgs args)
{
Console.WriteLine($"{nameof(SomeStandardEvent2)}:{args.ID}");
}
}
The output will look as follows:
If you did the same with Action<int> or Action<object, SomeStandardArgs>, you would only see SomeSimpleEvent2 and SomeStandardEvent2.
So whats going on inside of event?
If we expand out FireNiceEvent, the compiler is actually generating the following (I have omitted some details with respect to thread synchronization that isn't relevant to this discussion):
private EventHandler<SomeStandardArgs> _OnFireNiceEvent;
public void add_OnFireNiceEvent(EventHandler<SomeStandardArgs> handler)
{
Delegate.Combine(_OnFireNiceEvent, handler);
}
public void remove_OnFireNiceEvent(EventHandler<SomeStandardArgs> handler)
{
Delegate.Remove(_OnFireNiceEvent, handler);
}
public event EventHandler<SomeStandardArgs> OnFireNiceEvent
{
add
{
add_OnFireNiceEvent(value)
}
remove
{
remove_OnFireNiceEvent(value)
}
}
The compiler generates a private delegate variable which is not visible to the class namespace in which it is generated. That delegate is what is used for subscription management and late binding participation, and the public facing interface is the familiar += and -= operators we have all come to know and love : )
You can customize the code for the add/remove handlers by changing the scope of the FireNiceEvent delegate to protected. This now allows developers to add custom hooks to the hooks, such as logging or security hooks. This really makes for some very powerful features that now allows for customized accessibility to subscription based on user roles, etc. Can you do that with lambdas? (Actually you can by custom compiling expression trees, but that's beyond the scope of this response).
To address a couple of points from some of the responses here:
There really is no difference in the 'brittleness' between changing
the args list in Action<T> and changing the properties in a class
derived from EventArgs. Either will not only require a compile
change, they will both change a public interface and will require
versioning. No difference.
With respect to which is an industry standard, that depends on where
this is being used and why. Action<T> and such is often used in IoC
and DI, and event is often used in message routing such as GUI and
MQ type frameworks. Note that I said often, not always.
Delegates have different lifetimes than lambdas. One also has to be
aware of capture... not just with closure, but also with the notion
of 'look what the cat dragged in'. This does affect memory
footprint/lifetime as well as management a.k.a. leaks.
One more thing, something I referenced earlier... the notion of late binding. You will often see this when using framework like LINQ, regarding when a lambda becomes 'live'. That is very different than late binding of a delegate, which can happen more than once (i.e. the lambda is always there, but binding occurs on demand as often as is needed), as opposed to a lambda, which once it occurs, its done -- the magic is gone, and the method(s)/property(ies) will always bind. Something to keep in mind.
On the most part, I'd say follow the pattern. I have deviated from it, but very rarely, and for specific reasons. In the case in point, the biggest issue I'd have is that I'd probably still use an Action<SomeObjectType>, allowing me to add extra properties later, and to use the occasional 2-way property (think Handled, or other feedback-events where the subscriber needs to to set a property on the event object). And once you've started down that line, you might as well use EventHandler<T> for some T.
If you follow the standard event pattern, then you can add an extension method to make the checking of event firing safer/easier. (i.e. the following code adds an extension method called SafeFire() which does the null check, as well as (obviously) copying the event into a separate variable to be safe from the usual null race-condition that can affect events.)
(Although I am in kind of two minds whether you should be using extension methods on null objects...)
public static class EventFirer
{
public static void SafeFire<TEventArgs>(this EventHandler<TEventArgs> theEvent, object obj, TEventArgs theEventArgs)
where TEventArgs : EventArgs
{
if (theEvent != null)
theEvent(obj, theEventArgs);
}
}
class MyEventArgs : EventArgs
{
// Blah, blah, blah...
}
class UseSafeEventFirer
{
event EventHandler<MyEventArgs> MyEvent;
void DemoSafeFire()
{
MyEvent.SafeFire(this, new MyEventArgs());
}
static void Main(string[] args)
{
var x = new UseSafeEventFirer();
Console.WriteLine("Null:");
x.DemoSafeFire();
Console.WriteLine();
x.MyEvent += delegate { Console.WriteLine("Hello, World!"); };
Console.WriteLine("Not null:");
x.DemoSafeFire();
}
}
Looking at Standard .NET event patterns we find
The standard signature for a .NET event delegate is:
void OnEventRaised(object sender, EventArgs args);
[...]
The argument list contains two arguments: the sender, and the event arguments. The compile time type of sender is System.Object, even though you likely know a more derived type that would always be correct. By convention, use object.
Below on same page we find an example of the typical event definition which is something like
public event EventHandler<EventArgs> EventName;
Had we defined
class MyClass
{
public event Action<MyClass, EventArgs> EventName;
}
the handler could have been
void OnEventRaised(MyClass sender, EventArgs args);
where sender has the correct (more derived) type.