I have an event delegate that is defined as follows:
public delegate void CallbackDelegate(Data data);
public event CallbackDelegate OnDataComplete;
I raise the event asynchronously:
// Raise the OnDataComplete event
OnDataComplete.BeginInvoke(new Data(), null, null);
Subsequently, the signature of BeginInvoke looks like:
IAsyncResult CallbackDelegate.BeginInvoke(Data data, AsyncCallback callback, object #object)
In most examples I've seen BeginInvoke is called with the #object parameter being null, but I can't find the documentation which explains what is the purpose of that parameter.
So what is the purpose of that parameter? What can we use it for?
You can provide anything you want there. In the AsyncResult method you can retrieve this value with IAsyncResult.AsyncState. It's there for your use.
It's so that you can pass any relevant information from your method to the callback. Since C# has lambda expressions and since delegates can have state, sometimes this is useless, and you can just pass null. But it's a bit similar to Control.Tag, and it lets you give information to the callback that it might find handy.
Update:
The origin of why it even exists goes back to languages that only had function pointers, with no closure. (You might want to look up the word "closure"... I can't explain it very concisely.) In C, there's only function pointers and not delegates; hence, function pointers can't hold state. So whenever you provided a callback, the callee helped you by passing an additional pointer for you, so you could pass data to your callback that it might need. In .NET, these are less necessary (because delegates have Target objects and can hold state), but sometimes they're handy and that's where they come from.
That's just a state object that ends up in IAsyncResult.AsyncState that can be retrieved in your AsyncCallback code. Kinda like the ThreadPool.QueueWorkItem(WaitCallback, Object).
Related
I am trying to desconstruct a method written by another coder to see how it works but it's getting a bit confusing
We have a Delegate that takes an Action as parameter.
private delegate void FunctionDelegate(Action next);
A function is then called in the constructor that takes an array of these delegates as parameter and executes each value in the array
LoadInSeries(LoadRoleAreaHours, LoadTableData);
The Function looks like this
private void LoadInSeries(params FunctionDelegate[] _delegates)
{
var Delegates = new List<FunctionDelegate>(_delegates);
Func<Action, Action> creator = null;
creator = delegate(Action inner)
{
if (Delegates.Count > 0)
{
FunctionDelegate L = Delegates.First();
Delegates.RemoveAt(0);
Action next = delegate { L(inner); };
return creator(next);
}
else return inner;
};
Action outer = creator(null);
if (outer != null)
outer();
}
The intent was too chain a series of functions with each function calling the next but wouldnt it just be easy to use a multicast delegate and add each function to the invocation list.
Does this code do something different?
Without a good Minimal, Complete, and Verifiable code example, it's impossible to understand the code fully. Of most significant concern is that your code example includes a mysterious L() method, the behavior of which we have no idea. There is also the problem with the FunctionDelegate = Delegates.First(); statement. At best, the FunctionDelegate identifier refers to a class field or property; at worst, that statement won't even compile. Either way, there's no evidence that the delegate object being removed from the input list is ever actually invoked.
So to even answer the question, some basic assumptions have to be made, which may or may not be correct.
That said, in the best-case scenario — which is that the code has hidden some awful, convoluted mechanism in the L() method that ultimately winds up able to invoke the delegate for the current call to the creator delegate — the code you're looking at is not simply invoking delegates in sequence, as would be the case with a MulticastDelegate. Rather, the code is constructing a chain of calls to the L() method, passing each delegate instance to the method in sequence.
Since you didn't show us the L() method, there's no way to say what the code actually does. I would agree that if all that L() does is invoke the delegate you pass to it, then this code looks like a very complicated way to just invoke an array of delegates. But, giving the benefit of the doubt to the person who wrote the code, this simply means that L() probably does something other than simply invoke the delegate.
Of course, it's possible the author of the code doesn't deserve the benefit of the doubt. In that case, not only would it be simpler to just use a multicast delegate, the simplest implementation would just iterate over the array, invoking each delegate in the desired sequence. But I say that without really knowing what the code does. I'm just assuming it's intended to do something useful with the delegates that are passed to it. There's no evidence in the code you posted to support even that generous assumption.
Give us the full picture, and a more definitive answer can be provided. Without knowing what L() is, or what side effects might exist in the passed-in delegates' target methods, it's impossible to say for sure whether the code you're looking at really needs to be written that way or not.
According to the MSDN documentation, it says it's useful for following purposes in addition to others which are understandable:
A class may need more than one implementation of the method.
It is desirable to encapsulate a static method.
Can someone help me understand these usages with an example?
A delegate is a reference to a method that you can pass around as an object.
Imagine how useful it could be to have a method that allows its callers to provide part of its own logic. Every caller can have their own method, create a delegate (reference) to their method, and pass it to the method as a parameter. As long as the main method knows what arguments to pass in (if any), it can invoke the method by its reference (delegate).
Here's a simple example, specifically of usage #1 in your question:
void RemoveItem(string item, Action preRemoveLogic)
{
preRemoveLogic(); //we don't know what method this actually points to,
//but we can still call it.
//remove the item
}
void MyCustomLogic()
{
//do something cool
}
/* snip */
RemoveItem("the item", new Action(MyCustomLogic));
//I can pass a reference to a method! Neat!
Delegates are also very important for making events work in .NET.
I am going through a course on developing extensible software on pluralsight and in one of the slides, this code comes up. My understanding of delegate so far has been that it is used to point to other methods but i cannot figure out what's the purpose of delegate here and if anyone can point me in the right direction please.
As written there, it isn't very useful... They could have used Action<OrderItemProcessedEventArgs> and it would have been equivalent. (Action<> is the generic delegate for methods that don't return anything. Its official description is something like Encapsulates a method that has a single parameter and does not return a value.)
The delegate as written (and the Action<OrderItemProcessedEventArgs>) represent a method that returns void (so that doesn't return anything) and that accepts a single OrderItemProcessedEventArgs argument. So for example:
public void MyMethod(OrderItemProcessedEventArgs arg)
{
}
would be a method compatible with that delegate.
Now... that big block of code creates a CommerceEvents, that seems to be a container of events (not C#-events, directly delegates), that some pieces of code can "subscribe" by assigning methods to the properties (OrderItemProcessed in this case). Some other code, when necessary, will call OrderItemProcessed(someOtherItemProcessedEventArgs), passing a "descriptor" of why the "event" was executed (the OrderItemProcessedEventArgs class)
The delegate you have declared, represents any method which takes a generic T argument and returns void. T can be any class. You can also look into Func and Action delegates which are also generic in nature.
I have done a lot of reading about Control.Invoke and Control.BeginInvoke and understand that Invoke is like SendMessage() and BeginInvoke is like PostMessage(), but I do not understand where the parameter list passed via new object[] { arg, arg, arg, ...} is stored. During a conventional call, parameters are pushed to the stack and popped within the called function, then the call frame is recovered from the stack after exit, I assume releasing any references to any heap objects, allowing them to be collected. So, where is the pushed stack date for Invoke/BeginInvoke stored? How does it get disposed once the method called exits?
Also, I have successfully invoked a control method without loading a new object array with the pass parameters. Why would this work? Better yet, since it does work, why would all the examples I have ever seen show it with a new object array?
This is what I have always seen and used:
BeginInvoke(FormReceiveEvent, new object[] { Event, Arg1, Arg2, Arg3 });
But this works too:
BeginInvoke(FormReceiveEvent, Event, Arg1, Arg2, Arg3);
Any information and comments are always appreciated...
Thanks in advance.
The object[] containing the parameters is stored internally by the BeginInvoke method while it asynchronously invokes the target delegate. The reference to the array is released once the asynchronous call completes, allowing the array and its contents (assuming they are not otherwise reachable) to be collected.
The BeginInvoke(FormReceiveEvent, Event, Arg1, Arg2, Arg3); form works because the second parameter to BeginInvoke is defined as params object[]. This means that if you don't explicitly create an array, the compiler will do it for you. Therefore, the two calls are identical in terms of runtime behaviour.
A note on terminology: in the context of .Net, to say that an object is "disposed" typically means that the object implements IDisposable and that its IDisposable.Dispose method got called. In the context of Control.BeginInvoke and Control.Invoke, that does not happen.
After the asynchronous call finishes, the reference to the object[] is released so it can be collected, but if any of its members implement IDisposable, the IDisposable.Dispose method is not called. The object's resources will not be released until it is collected (or someone else disposes it).
Not always its true that a passed param is stored on stack. Only if its valuetype its stored. Other wise a ref is stored there looking at heap for that ref type.
In this case, the same holds good too. And difference b.w object array and passing as individual array, i guess its the allocation on stack. If you pass them seperately more stack space is allocated. Where as, a ref is allocated in stack pointing out to N number of array objects in heap.
Feel free to correct me.
When passing some object to Control.Invoke or Control.BeginInvoke, you are passing a parameters to a "method", it is no different from passing parameters to any method. However if you curios about the Invoke and BeginInvoke implementation you can check it in this answer.
For the second part of the question the signiture of BeginInvoke is:
BeginInvoke(Delegate method, params object[] args);
So you are asking about the params keyword, which is a special keyword that allow you to pass n arguments or array of specific type to method.
The params keyword lets you specify a method parameter that takes a variable number of arguments.
You can send a comma-separated list of arguments of the type specified in the parameter declaration, or an array of arguments of the specified type. You also can send no arguments.
I understand delegates encapsulate method calls. However I'm having a hard time understanding their need. Why use delegates at all, what situations are they designed for?
A delegate is basically a method pointer. A delegate let us create a reference variable, but instead of referring to an instance of a class, it refers to a method inside the class. It refers any method that has a return type and has same parameters as specified by that delegate. It's a very very useful aspect of event. For thorough reading I would suggest you to read the topic in Head First C# (by Andrew Stellman and Jennifer Greene). It beautifully explains the delegate topic as well as most concepts in .NET.
Well, some common uses:
Event handlers (very common in UI code - "When the button is clicked, I want this code to execute")
Callbacks from asynchronous calls
Providing a thread (or the threadpool) with a new task to execute
Specifying LINQ projections/conditions etc
Don't think of them as encapsulating method calls. Think of them as encapsulating some arbitrary bit of behaviour/logic with a particular signature. The "method" part is somewhat irrelevant.
Another way of thinking of a delegate type is as a single-method interface. A good example of this is the IComparer<T> interface and its dual, the Comparison<T> delegate type. They represent the same basic idea; sometimes it's easier to express this as a delegate, and other times an interface makes life easier. (You can easily write code to convert between the two, of course.)
They are designed, very broadly speaking, for when you have code that you know will need to call other code - but you do not know at compile-time what that other code might be.
As an example, think of the Windows Forms Button.Click event, which uses a delegate. The Windows Forms programmers know that you will want something to happen when that button is pressed, but they have no way of knowing exactly what you will want done... it could be anything!
So you create a method and assign it to a delegate and set it to that event, and there you are. That's the basic reasoning for delegates, though there are lots of other good uses for them that are related.
Delegates are often used for Events. According to MSDN, delegates in .NET are designed for the following:
An eventing design pattern is used.
It is desirable to encapsulate a static method.
The caller has no need access other properties, methods, or interfaces on
the object implementing the method.
Easy composition is desired.
A class may need more than one implementation of the methodimplementation of the method
Another well put explanation from MSDN,
One good example of using a
single-method interface instead of a
delegate is IComparable or
IComparable. IComparable declares the
CompareTo method, which returns an
integer specifying a less than, equal
to, or greater than relationship
between two objects of the same type.
IComparable can be used as the basis
of a sort algorithm, and while using a
delegate comparison method as the
basis of a sort algorithm would be
valid, it is not ideal. Because the
ability to compare belongs to the
class, and the comparison algorithm
doesn’t change at run-time, a
single-method interface is ideal.single-method interface is ideal.
Since .NET 2.0 it has also been used for anonymous functions.
Wikipedia has a nice explanation about the Delegation pattern,
In software engineering, the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object. It passes the buck, so to speak (technically, an Inversion of Responsibility). The helper object is called the delegate. The delegation pattern is one of the fundamental abstraction patterns that underlie other software patterns such as composition (also referred to as aggregation), mixins and aspects.
Oversimplified: I'd say that a delegate is a placeholder for a function until that time when something assigns a real function to the delegate. Calling un-assigned delegates throws an exception.
Confusion occurs because there is often little difference made between the definition, declaration, instantiation and the invocation of delegates.
Definition:
Put this in a namespace as you would any class-definition.
public delegate bool DoSomething(string withThis);
This is comparable to a class-definition in that you can now declare variables of this delegate.
Declaration:
Put this is one of function routines like you would declare any variable.
DoSomething doSth;
Instantiation and assignment:
Usually you'll do this together with the declaration.
doSth = new DoSomething(MyDoSomethingFunc);
The "new DoSomething(..)" is the instantiation. The doSth = ... is the assignment.
Note that you must have already defined a function called "MyDoSomething" that takes a string and returns a bool.
Then you can invoke the function.
Invocation:
bool result = doSth(myStringValue);
Events:
You can see where events come in:
Since a member of a class is usually a declaration based upon a definition.
Like
class MyClass {
private int MyMember;
}
An event is a declaration based upon a delegate:
public delegate bool DoSomething(string withWhat);
class MyClass {
private event DoSomething MyEvent;
}
The difference with the previous example is that events are "special":
You can call un-assigned events without throwing an exception.
You can assign multiple functions to an event. They will then all get called sequentially. If one of those calls throws an exception, the rest doesn't get to play.
They're really syntactic sugar for arrays of delegates.
The point is of course that something/someone else will do the assigning for you.
Delegates allow you to pass a reference to a method. A common example is to pass a compare method to a sort function.
If you need to decide at runtime, which method to call, then you use a delegate. The delegate will then respond to some action/event at runtime, and call the the appropriate method. It's like sending a "delegate" to a wedding you don't want to attend yourself :-)
The C people will recognize this as a function pointer, but don't get caught up in the terminology here. All the delegate does (and it is actually a type), is provide the signature of the method that will later be called to implement the appropriate logic.
The "Illustrated C#" book by Dan Solis provides the easiest entry point for learning this concept that I have come across:
http://www.amazon.com/Illustrated-2008-Windows-Net-Daniel-Solis/dp/1590599543
A delegate is typically a combination of an object reference and a pointer to one of the object's class methods (delegates may be created for static methods, in which case there is no object reference). Delegates may be invoked without regard for the type of the included object, since the included method pointer is guaranteed to be valid for the included object.
To understand some of the usefulness behind delegates, think back to the language C, and the printf "family" of functions in C. Suppose one wanted to have a general-purpose version of "printf" which could not only be used as printf, fprintf, sprintf, etc. but could send its output to a serial port, a text box, a TCP port, a cookie-frosting machine, or whatever, without having to preallocate a buffer. Clearly such a function would need to accept a function pointer for the character-output routine, but that by itself would generally be insufficient.
A typical implementation (unfortunately not standardized) will have a general-purpose gp_printf routine which accepts (in addition to the format string and output parameters) a void pointer, and a pointer to a function which accepts a character and a void pointer. The gp_printf routine will not use the passed-in void pointer for any purpose itself, but will pass it to the character-output function. That function may then cast the pointer to a FILE* (if gp_printf is being called by fprintf), or a char** (if it's being called by sprintf), or a SERIAL_PORT* (if it's being called by serial_printf), or whatever.
Note that because any type of information could be passed via the void*, there would be no limit as to what gp_printf could do. There would be a danger, however: if the information passed in the void* isn't what the function is expecting, Undefined Behavior (i.e. potentially very bad things) would likely result. It would be the responsibility of the caller to ensure that the function pointer and void* are properly paired; nothing in the system would protect against incorrect usage.
In .net, a delegate would provide the combined functionality of the function pointer and void* above, with the added bonus that the delegate's constructor would ensure that the data was of the proper type for the function. A handy feature.