C # - Win Forms - Event Flow Loop
I was reading a line from Jon Skeet in C #. He declared:
"Events are closely related to delegates, but they are not the same thing."
So, from my understanding, when events occur, handlers (delegates) execute the code.
I have the following doubts:
(1) When we announce an event, will it be registered in any "REGISTRATIONS"? or "System Registers"?
(2) Old VB 6.0 style handles event without delegates, so why can't we write event without delegates?
How does the flow for Win Forms work: if I click the button, it prints hello (in the following example).
button_click( sender,some event args )
{
print();
}
void print( )
{
console.WriteLine ("Hello");
}
How is this stream of events internally linked and handled? (What's going on internally in the CLR?)
(3) What is the event logic that prevents the event from returning?
Thank you all for wasting your golden time.
source to share
A is a type definition. It indicates to the signature that the method should be compatible. delegate
An is a property-like class member based on the delegate type. It provides encapsulation, the only public actions are Add (+ =) or Remove (- =) handler. event
(1) No, the event is not registered anywhere. But this is where processing methods are recorded.
(2) I don't know how VB6 works, but in .NET all events are delegate based.
(2b) What happens when the button is clicked is that the button code checks to see if it is an event and then raises the event (like a method). The event iterates over the Invocation list and invokes all registered handlers.
there is a bit more, ButtonClick is triggered by the button itself when it handles and handles mouse and / or keyboard events. These events originate from MessageLoop (Application.Run). But at the CLR level, this means that MessageLoop calls the (Control.Perform (..)) method on the button.
(3) You can write a delegate and / or an event that returns a value just fine. But think about what it means when there are multiple handlers. A signature void handler(object sender, Eventargs e)
is a (strong) recommendation.
source to share
Events are implemented using delegates :
This code:
public event EventHandler<YourEventArgs> YourEvent;
Something like this will be compiled:
// a private field
private EventHandler<YourEventArgs> YourEvent = null;
// public add_ method
[MethodImpl(MethodImplOptions.Synchronized)]
public void add_YourEvent(EventHandler<YourEventArgs> value)
{
YourEvent = (EventHandler<YourEventArgs>)
Delegate.Combine(YourEvent, value);
}
// public remove_ method
[MethodImpl(MethodImplOptions.Synchronized)]
public void remove_YourEvent(EventHandler<YourEventArgs> value)
{
YourEvent = (EventHandler<YourEventArgs>)
Delegate.Remove(YourEvent, value);
}
So, when you declare an event, you are actually declaring these 2 functions. As you can see, these functions encapsulate access to the delegate field. This is why you cannot assign a delegate value to an event, only subscribe or unsubscribe.
This code explains why events can be declared using the following syntax:
public event MyDelegate MyEvent
{
add
{
...
}
remove
{
...
}
}
1) The event will not be registered in any registry. Memory for the event (for the private delegate field) will be allocated on the heap because delegates are reference types.
2) Events are built on top of delegates, so you cannot use them without delegates.
3) The third question has already been answered by Henk Holterman (+1) and other people.
Hope it helps.
source to share
-
I don't know this ... but my first thought is in the heap, since that's where most objects live and events are part of the object .... but I dare to guess this alone ....
-
They actually do it behind the scenes. This is a feature of VB.
-
They can have more than one delegate / listener and the order in which listeners are fired is not guaranteed. The convention is to use the eventarg object to return information to the handler. Why don't events have return types in .NET? this one describes it a little better.
source to share
1) No, event handlers will just be registered with Event (which contains a list of handlers).
2) I'm not very good with VB6, but I'm pretty sure it had a similar mechanic, since, in essence, a delegate is just a typed method pointer.
In your example, the event Button.Click
contains a reference to the delegate button_click( sender,some event args)
that it calls when the event fires. It doesn't contain any print references, just a reference to the method it should call.
3) Since there can be multiple handlers for the same event (or nothing at all), having a return value can often be counterintuitive. Thus, most event handlers have a void
return. With this, you can create custom events that can have any signature. The signature void (object sender, EventArgs e)
is the base signature for most, if not all, Microsoft events.
source to share