Hi all, what is the advantage of raising and event in asp.net user controls?
+5
A:
To allow someone else to execute code when you do something, without having to poll your state to know what you've done.
Noon Silk
2009-08-23 22:21:48
can you provide an example?
2009-08-23 22:23:00
Of an event? 'OnLoad' is an event of 'Page', in ASP.NET. What language are you talking about? What sort of example do you want?
Noon Silk
2009-08-23 22:29:45
So the page is raising an OnLoad event. Would that be a correct phrase?
2009-08-23 22:37:38
Page is raising the 'Load' event. And in C#, you can attach an event handler to this event via Page.Load += new EventHandler(yourFunction).
Noon Silk
2009-08-23 22:40:13
That makes sense. Thanks
2009-08-23 22:42:17
+2
A:
The purpose of raising an event is typically to inform about something that has happened or is about to happen in the code, in order to allow other parts of the program to react on this. Usually the events are designed in a way so that the code that raises the event works the same way regardless of whether there are any listeners (event handlers) attached or not.
One example would be the click event of a button. When the user clicks the button, the button will raise a click event, which will allow any attached event handler to do something. But if there is not event handler attached, the button will not change its behavior (it's just that nothing will happen).
Though most events are raised to inform that something has happened, there are some events that are raised in order to inform that something is about to happen. Sometimes these event use an EventArgs class with read/write properties (as opposed to readonly properties which are more commonly found in EventArgs classes) which allows the event listener to communicate data back to the event-raising code. I can't come up with any good asp.net example from the top of my head, but in the winforms world a typical example of this would be the Form.Closing event, where the event handler can set e.Cancel = true to prevent the form from closing.
So, in a user control it would be useful to raise an event whenever it may be of interest for external code (typically the page) to react on something that happens within the control.
Fredrik Mörk
2009-08-23 22:40:42
A:
To add to the other answers already here, let me use an analogy to explain events.
Suppose you wish to receive newspapers each day. You telephone the newspaper company to inform them that you wish to receive any new newspapers they may print - you 'subscribe' to the newspaper. The newspaper delivery people maintain a list of people who are subscribers - people who should receive the paper. When the newspaper is printed each day, if you are on the subscriber list, you will receive a newspaper.
Now, suppose you have an object - a button, for instance. Suppose you want to know when that button is pressed. You 'subscribe' to events - specifically an 'OnClick' or 'OnPressed' or whatever it may be named in your language of use. Whenever the user clicks the button, the button goes through its list of subscribers, and calls the function supplied to each. These are the 'event handlers'. These functions are what the subscribers want to have called when the event occurs. In English, the subscriber might say "When you're pressed, call MyOnClick() function."
Events are used in many programming paradigms to cope with complexity - events do not need to know anything about event handlers, and vice versa. This allows for looser coupling, and more modular, reusable code.
I suggest you read about the Observer Pattern, as this is the foundation for events and event handlers.
Charlie Salts
2009-08-23 22:57:50