CancelEventArgs provides a Property called Cancel that different event handlers can set to tell the object that invoked the event whether it should continue execution cancel the action.
It seems that since events are multicast delegates, a simple raise of the event might invoke two delegates. The first one sets the Cancel property to true, the second one sets the Cancel property to false. Do component/framework 'cancelable' events support these scenarios and invoke each delegate one by one, checking the cancel flag at each step? What is the best practice to raise these types of events? Is only one instance of CancelEventArgs passed to each delegate? Are separate instances used?
A little experiment quickly shows that they use 1 instance of Cancel (probably of the EventArgs object).
That makes it a bit of a gamble, with the outcome depending on the order in which the Eventhandlers were attached.
In the particular case of the CancelEventArgs I think the correct pattern would be to set Cancel to true or leave it alone, so the order shouldn't matter.
Tested:
public static void Main() {
Event += (sender, e) => e.Cancel = true;
Event += (sender, e) => e.Cancel = false;
Event += (sender, e) => e.Cancel = true;
var args = new CancelEventArgs();
Event(null, args);
WL(args.Cancel);
}
static event EventHandler<CancelEventArgs> Event;
The order of attached event handlers does matter.
Generally speaking, events with non-immutable event args and multicast delegates should not used together, but the .NET framework uses such events very extensively.
Related
Edit: this question is not about how to unsubscribe from events because I know how to do that if I want to. The question is about if there is a conflict with garbage collection in my specific scenario.
In some code I wrote a while ago I registered an event (CheckExecution, owned by isoDataTemp, see code below) by means of an anonymous method. But now it has come to my mind that assigning an anonymous method to an event is pretty evil because there is no way to unregister the method from the event, right? I once had a problem with an object that could not be garbage collected because an event was still pointing to it.
So I wonder if I can get into trouble with it here. My spontaneous reaction is "no, because the anonymous method belongs to the MainForm and this has longer lifetime than its isoDataTemp member". But I am not sure. What about closures? Does the anonymous method belong to MainForm at all. I am confused...
public partial class MainForm : Form
{
// ...
void BackgroundWorkerISOAnalysisDoWork(object sender, DoWorkEventArgs e)
{
BackgroundWorker worker = sender as BackgroundWorker;
int prog = 0;
isoDataTemp.CheckExecution += () =>
{
prog += 12;
if (prog > 100) prog = 100;
worker.ReportProgress(prog);
return !worker.CancellationPending;
};
isoDataTemp.Analyze();
if (worker.CancellationPending) e.Cancel = true;
}
}
To unregister all event handlers for an event that you own, simply use this code:
isoDataTemp.CheckExecution = null;
Note that this works for anonymous and non-anonymous event handlers.
From your example, you can add this code to your OnFormClosing event, to ensure that events assign to your isoDataTemp object are properly and completely removed.
Note that if the isoDataTemp object is a child object of the form object, then it will be removed when your Form object is destroyed and will be garbage-collected along with the destroyed Form object instance, as expected.
It is possible to execute the following code from multiple threads simultaneously.
this._sequencer.Completed += OnActivityFinished;
Is it thread safe to add delegate to an event handler from multiple threads?
Is it thread safe to remove delegate to from event handler from multiple threads?
What is the simplest and maintainable way of making this thread safe?
If you don’t specify your own event add/remove handlers, the C# compiler generates this add handler (reconstructed by .NET Reflector):
public void add_MyEvent(EventHandler value)
{
EventHandler handler2;
EventHandler myEvent = this.MyEvent;
do
{
handler2 = myEvent;
EventHandler handler3 = (EventHandler) Delegate.Combine(handler2, value);
myEvent = Interlocked.CompareExchange<EventHandler>(ref this.MyEvent, handler3, handler2);
}
while (myEvent != handler2);
}
and a remove handler that looks the same but with Delegate.Remove instead of Delegate.Combine.
Notice the use of Interlocked.CompareExchange? This prevents a race condition between updating the event’s backing field and reading from it. Thus, it is thread-safe.
It depends on the implementation of the event, to be honest.
The field-like events generated by the C# compiler are thread-safe, but if it's a custom event, who knows?
Note that in a multi-threaded app you should expect a race condition between adding/removing a handler and the event firing... for example, the event may start to fire, you could then unsubscribe, and your handler would still be called after that unsubscription.
for field-like events adding/removing of handlers is thread-safe. From spec:
When compiling a field-like event, the compiler automatically creates storage to hold the delegate, and creates accessors for the event that add or remove event handlers to the delegate field. In order to be thread-safe, the addition or removal operations are done while holding the lock (§8.12) on the containing object for an instance event, or the type object (§7.6.10.6) for a static event.
However it is true for C# 3.0 and lesser, in C# 4.0 compiler generates lock-free implementation using Interlocked routines (but spec remains the same - bug?)
In custom implementations no one can tell exactly... except maybe the author of code :)
I would like to confirm something - when I register a method as a subscriber to an event the long way, like so:
_serviceContext.ReadingEntity += new EventHandler<ReadingWritingEntityEventArgs>(_serviceContext_ReadingEntity);
I need to un-register that method from the event's subscription if I don't want it to continue to be called when the event is fired, like this:
_serviceContext.ReadingEntity -= new EventHandler<ReadingWritingEntityEventArgs>(_serviceContext_ReadingEntity);
When I register a delegate as a subscriber to an event, like so:
public guy ThisMethod()
{
_serviceContext.ReadingEntity += delegate(object sender, ReadingWritingEntityEventArgs e)
{
};
}
There is no way to un-register that delegate from the subscriber list from that method. So I am assuming that the scope of this registration is limited to the method in which it's registered - i.e. if the _serviceContext.ReadingEntity event was fired in a method called by ThisMethod, this registration would be already expired and the code inside the delegate would not run. Is this correct?
Thanks!
p.s. I realize that the first "long" way of registering an event handler also has scope limitations, but I'm a bit hazy on that. My main question, however, is whether or not the delegate registration will live on outside of the method above.
Once you subscribed a delegate this way (you can unsubscribe using -= operator if you cache the delegate variable somewhere) you can't remove it from subscribers list and it will be invoked every time event rises until publisher is alive. Moreover this subscription will prevent any subscriber class (class which contains the method you subscribed to event) from garbage collection until publisher is alive (unless you use a static method).
To give some clarity, there is no "anonymous" methods in IL code. All your delegates and lamdbas are translated into static/instance methods and closure classes (depends on whether they use instance members/function parameters).
You can unsubscribe a delegate if you keep a reference to it.
EventHandler<ReadingWritingEntityEventArgs> aDelegate = delegate(object sender, ReadingWritingEntityEventArgs e)
{
};
_serviceContext.ReadingEntity += aDelegate;
_serviceContext.ReadingEntity -= aDelegate;
If you do not do it this way, there is no way to unsubcribe. The scope is not limited to the method in which it was registered. It will be registered for the lifetime of the event.
I know this is really basic stuff but I'm struggling to wrap my mind around it.
Ok so I have a method that I want to run:
public static void DelegateTest(string testStuff)
{
for (int i = 0; i < 4; i++)
{
Console.WriteLine(testStuff);
}
}
Then, outside of the scope of this method (but within the scope of my class) I define my delegate with the same output type and input parameters as my method:
public delegate void myDelegate(string test);
I instantiate my delegate like so:
myDelegate md = new myDelegate(DelegateTest);
I can then kick off my method as many times as I like by BeginInvoking the delegate, and the methods will run side by side in separate threads.
md.BeginInvoke("Hello World", null, null);
md.BeginInvoke("Hello World Again", null, null);
md.BeginInvoke("Hello World A Third Time", null, null);
How do I now define an event and only kick off my method asynchronously when the event happens? Also, what are the limitations on what an event can be? Can more or less anything that happens on my computer be defined as an event or only certain things?
Edit: Say for example, after doing the above, I want to create an event and define this event as 'the space bar has been pressed'. Every time the space bar is pressed, this is the event happening. When the event happens, I want to start my method asynchronously, I don't want to start my method asynchronously if the space bar hasn't been pressed.
How would I go about this?
Just use Invoke rather than BeginInvoke for synchronous calls.
EDIT: as per ThePower's answer, you don't need the Invoke, you can just call your delegate as if it were a function (because it is!).
EDIT2: You are actually trying to register an event handler. For this you don't need to create your own delegate. An example for handling the KeyPress event in WinForms:
public class MyForm : Form
{
public MyForm()
{
KeyPress += OnKeyPressHandler;
}
private void OnKeyPressHandler(object sender, KeyPressEventArgs keyPressEventArgs)
{
//TODO: whatever you need to do...
}
}
If you want to use it as an event, check out the event type. There's a good example here.
Although, if you want to use your delegate...
You have already defined Asynchronous, so for Synchronous use :
md("Hello World", null, null);
md("Hello World Again", null, null);
md("Hello World A Third Time", null, null);
I'm not sure I completely understand your question. In C#, for all practical purposes, an event is a delegate, meaning that any delegate can be used as an event.
Using your example:
public delegate void MyDelegate(string test);
You can now use MyDelegate as an event in a class:
public class MyClass
{
public event MyDelegate MyEvent;
}
You can now register event handlers with MyEvent and then in the event handler you can execute any code you want. From a traditional sense, this is the only way to define events in C#.
Another option to consider is using a publish/subscribe pattern such as an EventAggregator. This pattern doesn't typically rely on delegates and instead relies on an aggregator object to notify all subscribers of a published event. In this scenario, the event can really be any object that contains the information expected by the subscribers.
I recently attended a interview in C# where i was asked a question about Events and delegates in C#
The person asked me when a event say button gets clicked, which gets called first event or delegate?
Does the delegate calls the event or the event calls delegate?
Can we have a event without a delegate in c#?
The person asked me when a event say button gets clicked, which gets called first: the event or the delegate?
When you open a door, which gets opened first: the door or the doorknob?
Huh?
That question doesn't make any sense. You open a door with a doorknob, but you don't open a doorknob.
What does it mean to "call" an event? Events aren't things that you call. Events are things that you raise. Raising an event is identical with calling the delegate.
Does the delegate calls the event or the event calls delegate?
Does the door open the doorknob, or does the doorknob open the door?
Again, the question doesn't make sense. A doorknob is not something that can be "opened", and the doorknob does not open the door -- you open the door, by holding the doorknob.
Does the delegate call the event? No; events are not things that can be "called". Does the event call the delegate? No, the code that is raising the event calls the delegate.
Can we have a event without a delegate in c#?
Yes, in the sense that the delegate reference associated with an event can be a null reference. But every event is associated with a delegate type, and somehow has associated with it a reference to a delegate.
The whole set of questions indicates to me that the questioner does not have a very good understanding of the relationship between events and delegates. A good way to think about it is that an event is just a property that contains a reference to a multicast delegate. Whereas a property has special methods that get and set the value of the property, an event has special methods that add and remove delegates to the multicast delegate.
Events are a concept which utilize delegates as a means to call methods that have subscribed to them.
Events themselves are not called. When a piece of code raises an event, it will call each of the subscribed methods by invoking the delegates.
Events are raised, delegates are called. So when the button is clicked, a buttonClick event is raised, meaning that each delegate subscribed to the event will be called, according to the subscription order.
An event is simply a code construct implemented in .NET as a multi-cast delegate.
When an event is "raised" (which can only be done by code in the same class as the event; event raising must happen within "protected" scope), the delegates are invoked one at a time, in a synchronous fashion but not necessarily in any deterministic order. The event IS the delegate, so when the event is raised for a button being clicked, the delegates are invoked by the runtime, which has received the Windows message that the user clicked on the GUI area for the button.
The statements "the event is raised" and "the delegates are invoked" are equivalent statements; it's like asking "which comes first, the chicken or the gallus domesticus?".
Now, events often cascade, especially when we're talking about UI. There is a MouseUp event, invoked when the mouse button is released, which can fire one or more other events such as MouseClick, MouseDoubleClick, DragDrop, etc. You may not attach a handler to the MouseUp event, but there is built-in logic behind the scenes of MouseUp to raise the MouseClick event which you DO handle. So, in this sense, you could say that the MouseUp event "comes first" and calls the MouseClick handler delegate.
This page bubbled up on top of Google results, so below is something you might find useful if you also land here. Multi-cast delegates ARE called (see MSDN) in deterministic order on one thread, in the order of assignment. This assignment will involve an array of some sort, and it would be illogical for the indices to fill up out of order.
public partial class Form1 : Form
{
ob<Control>ob1;
ob<Control>ob2;
ob<Control>ob3;
public Form1()
{
InitializeComponent();
ob<Control>.setup(button1);
ob1 = new ob<Control>(1, true);
ob2 = new ob<Control>(2, false);
ob3 = new ob<Control>(3, false);
}
public class ob<T> where T : Control
{
int ndx;
Boolean isSentinel;
static Boolean dontdostuff;
static T c;
public static void setup(T c) {ob<T>.c = c;}//an argument less from constructor, useful for many objects (more likely to be menuitems)
public ob(int ndx, Boolean isSentinel)
{
this.ndx = ndx;
this.isSentinel = isSentinel;
c.Click += new EventHandler(click);
}
void click(object sender, EventArgs e)
{
if( isSentinel)
{
if (MessageBox.Show("ob" + ndx + " asks: short circuit subsequent delegate calls?", "", MessageBoxButtons.OKCancel, MessageBoxIcon.Question) == DialogResult.OK)
{
dontdostuff = true;
return;
}
else
{
dontdostuff = false;
}
}
else
{
if( dontdostuff) return;
}
MessageBox.Show("ob" + ndx + " doing stuff in order of handler addition", "", MessageBoxButtons.OK, MessageBoxIcon.Information);
}
}