Tony said:
I'm reading a book about events and delegetes and it says the following.
"Again the important thing to remember is that there is no guarantee that
the label text changes before the MessageBox appears, so be careful not to
write dependent code in the handlers."
It is important to remember that, even though the default implementation
of an event uses a straight delegate field in the class, and even though
an event is closely associated with a delegate type, an event is _not_
the same thing as a delegate and will not necessarily have the same
behavior as one.
In particular, while multicast delegates have a specific definition
promising an order of invocation, there's no such guarantee for events.
For example, here's the default implementation for an event (this is
what's generated for you if you don't provide an implementation). If
you declare an event like this:
event EventHandler MyEvent;
The compiler will generate in your class code that actually looks
something like this (it will pick a different field name that I've shown
here, but otherwise this is what you get):
private EventHandler _myEventDelegate;
event EventHandler MyEvent
{
add
{
lock (this)
{
_myEventDelegate += value;
}
}
remove
{
lock (this)
{
_myEventDelegate -= value;
}
}
}
But, that's just the default implementation. There's no requirement an
event be implemented that way. A class could instead implement the
event explicitly, and write it like this:
private EventHandler _myEventDelegate;
event EventHandler MyEvent
{
add
{
lock (this)
{
_myEventDelegate = value + _myEventDelegate;
}
}
remove
{
lock (this)
{
_myEventDelegate -= value;
}
}
}
Note that the add method changes the order of concatenation. In the
above example, when the event is raised, handlers will be called in the
_reverse_ order of when they are added.
The _delegate_ is still following the rules in the C# specification:
order of invocation follows order of concatenation. But the event has
reversed the order of concatenation, and in so doing has also reversed
the order of invocation.
1. btnOne.Click += new EventHandler(lblInfo.Text = "Button One was
pressed"
;
2. btnTwo.Click += new EventHandler(lblInfo.Text = "Button Two was
pressed"
;
3. btnTwo.Click += new EventHandler(MessageBox.Show("This only happens in
Button 2 click event"
;
None of the above are valid C# statements.
So becuse of the text in the book is saying what it says does this mean that
this code
MessageBox.Show("This only happens in Button 2 click event"
;
can be executed before this code
(lblInfo.Text = "Button Two was pressed"
;
For an event, yes. That is a possibility. I don't think it will happen
with the Control class's events, because of the specific implementation
being used. But it's not documented to be that way, nor should your
code count on it.
If it would be in the same sequence as the code was executed then this code
lblInfo.Text = "Button Two was pressed"
;
would always be executed before this code
lblInfo.Text = "Button Two was pressed"
;
Uh, you wrote the same program statement twice above. With an event,
there's no guarantee of order anyway, so no matter what you'd meant to
write, you can't say for sure which order the event handlers will be called.
So can anybody explain why the book is saying what is says ?
I hope that the above explains it. Events are not the same as
delegates. What can be said about delegates may not necessarily also be
true for events.
Pete
