Shulou(Shulou.com)06/02 Report--

What this article shares with you is about the implementation event analysis in the development of ASP.NET server controls. The editor feels that it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

1. Basic concept of event

An event is a message or notification sent by a class when an action occurs or the state changes. Typically, the occurrence or change of state is initialized by user interface actions, such as clicking a button, or due to other program logic. The class that generates the event, or the class that sends notifications, is called the event source sender, and the class that receives the event is called the event receiver receiver. The relationship between the two is realized by delegate. A common application event code is listed below.

/ / declare event ClickcustomControl.Click + = new EventHandler (this.customControl1_Clicked); / / implement event handler customControl1_Clicked (object sender,EventArgs e) {.}

The code above enumerates the process for the ASP.NET server control to declare events and implement event handlers. Since this process is very simple, there will be no more explanation here. In addition, in practical applications, developers can simply list "OnClick = customControl1_Clicked" in the control declaration tag instead of declaring events in the above way by implementing the event mechanism for server controls. In fact, the declaration of events and the implementation of specific event handlers are relatively easy to use. However, it is not easy to implement an event mechanism for a control.

From the perspective of ASP.NET server control development, control events (which only refer to server-side events, not client-side events) may come from two aspects: one is events inherited from the base class. For example, if a custom control inherits from the Button class, the control inherits the Click event of the base class. The other is the custom events created according to the development requirements. These two events are described below.

two。 Implement events inherited from the base class

It is well known that custom ASP.NET server controls are ultimately derived from System.Web.UI.Control. Some events are already defined in this base class. Therefore, during the process of creating an ASP.NET server control, you will most likely need to override the following inherited events.

DataBinding event: this event occurs when the ASP.NET server control is bound to the data source, and its corresponding event handler is OnDataBinding.

Disposed event: this event occurs when server control resources are freed from memory, and its corresponding event handler is OnDisposed. This is the * phase of the server control life cycle.

Init event: this event occurs when the ASP.NET server control is initialized and its corresponding event handler is OnInit. The Init event is a step in the life cycle of a control.

Load event: this event occurs when the ASP.NET server control is loaded into a Page object, and its corresponding event handler is OnLoad.

PreRender event: this event occurs after the Control object is loaded and before rendering, and its corresponding event handler is OnPreRender.

Unload event: this event occurs when the ASP.NET server control is unloaded from memory, and its corresponding event handler is OnUnload.

The above provides a brief description of several events of the Control base class. Because server controls inherit from the Control base class (WebControl also inherits from the Control class), developers can completely override the event handler corresponding to the event so that some custom content can be implemented.

To implement custom inherited events, you need to override the protected OnEventName method inherited from the base class without attaching a delegate (EventHandler). In general, the overridden event handler should call the OnEventName method of the base class to ensure that delegates attached to the event are called (unless you don't want to call them). The following code snippet shows how the custom control overrides the inherited DataBinding event.

Protected override void OnDataBinding (EventArgs e) {/ / add some custom logic code / / call the base class method base.OnDataBinding (e);}

As shown in the above code, in the process of rewriting the event handler OnDataBinding, you first need to add some custom logic code that is implemented according to the application requirements, and then keep in mind that you need to call the base class methods.

The above introduces the events of the Control base class and the process of overriding the corresponding event handlers by derived classes. It is important to note that the above does not mean that custom server controls can only override the above event handlers from the Control base class events. If custom controls inherit from other base classes that originally have events, such as Button, DataList, and so on (which, in the final analysis, also inherit from the Control base class), inherited event handlers can still be overridden, for example, controls that inherit from the Button class naturally get Click events and can override OnClick event handlers.

3. Create a custom ASP.NET server control event

Before we introduce how to create custom server control events, let's briefly review the relevant event models.

On Web forms pages, events associated with ASP.NET server controls are raised by the client and handled by the Web server (note: events must be called "raise" instead of using words such as "trigger" and "fire", which are inaccurate and irregular). For events raised by ASP.NET server controls on the client, the ASP.NET event model collects information about the request and uses HTTP Post to pass the details to the server. The Page Framework on the server interprets the announcement to determine which event occurred, and then invokes the appropriate handler method. Figure 1 below briefly illustrates this process.

As shown in figure 1, on the client computer, the user clicks the Add button of the shopping cart to try to put the selected item into the shopping cart. After clicking, the event model collects relevant information, such as Submit = btnAddToCart,Prod3 = Gizmo, and so on, which is passed to the server through Post. After receiving the information, the server first analyzes it, and then calls the event handler btnAddToCart (obj,event) to process it. These are the basic event handling models.

For ordinary application developers, you only need to implement the control's event handler, and further information is hidden from them, and there is no need to pay more attention. However, as an ASP.NET server control developer, you must carefully consider this event handling model.

If readers think carefully about the above process, they will find two important problems that need to be solved in the event handling model. *, how does the server capture the click event returned to the server? second, how to handle the data sent back to the server through Post. The above two questions are crucial. If you can solve these two problems, it becomes very easy to create custom ASP.NET server control events.

To solve the above problems, ASP.NET provides two important interfaces: IPostBackEventHandler and IPostBackDataHandler. The IPostBackEventHandler interface is used to handle events raised by the client for page postbacks. To implement this interface, the ASP.NET server control corresponds the client-side submit form event to the server-side event, and handles the client-side event through an event handler. The IPostBackDataHandler interface is used to examine the data submitted to the page and to determine if it has been modified on the client side. When the control implements this interface, the control automatically has the ability to participate in the processing of returned data. Developers can complete the processing logic for the returned data by implementing the relevant members of the interface.

In fact, the vast majority of server controls in ASP.NET trigger a backhaul from the client to the server, and many of the server controls implemented by the reader must also trigger a backhaul. Therefore, the above two interfaces are very important for implementing control events. For them, this section only gives a brief introduction. In subsequent articles, readers will learn more about how to implement interface members, capture backhaul events, and deal with backhaul data through typical examples.

In addition, ASP.NET enhances the ability to handle callbacks. For example, use the System.Web.UI.ICallbackEventHandler interface and the Page.GetCallbackEventReference method, and so on. Through the application of these objects, it is possible to run server-side code on the client side, thus avoiding the loss of client state and the processing overhead of server round-trip. There is some connection between this content and server control events. However, callback applications are rarely used in ASP.NET server controls. Therefore, there will not be too much explanation.

From the perspective of technological development, ASP.NET technology has been upgraded from 1.x to 2.0 without any significant changes in the development of ASP.NET server control events. If you already know the content of creating server control events under ASP.NET 1.x, you can follow the methods and ideas of the past 1.x.

The above is what the implementation event analysis is in the development of ASP.NET server controls. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.