ASP. net2.0 server control development implementation event

The previous articles explain the use of ASP. NET 2.0 technology to create custom server control attributes. Starting from this article, several subsequent articles will explore how to create custom server control events. This article focuses on the basic concepts for implementing control events. These concepts are of great significance for developers to create events for server controls.

　　1. Basic concepts of events

An event is a message or notification sent by the class when an action occurs or the status changes. Generally, status changes are initiated by user interface actions, such as clicking a button or starting with other program logic. The class that generates the event or sends the notification is called the event source sender, and the class that receives the event is called the event receiver. The two are linked through a delegate (delegate. The following describes a common application Event code.

// Declare the event Clickcustomcontrol. Click + = new eventhandler (this. customcontrolpolicclicked ); // Implement the event handler Customcontrolpolicclicked (Object sender, eventargs e ){......}

The above Code lists the process of declaring events and implementing event handlers by server controls. This process is very simple and I will not explain it here. In addition, in practical applications, developers can implement the event mechanism for server controls without using the above event declaration methods, instead, just list "onclick = customcontrolpolicclicked" in the control declaration tag. In fact, the declaration of events and the implementation of specific event handlers are relatively simple and easy to use. However, implementing the event mechanism for controls is not easy.

From the perspective of server control development, control events (only server events, not client events) may come from two aspects: first, 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. Second, custom events created based on development needs. The two events are described below.

　　2. Events inherited from the base class

As we all know, custom server controls are derived from system. Web. UI. Control. Some events have been defined in the base class. Therefore, when creating a server control, you may need to override the following inherited events.

· Databinding event: when the server control is bound to the data source, the corresponding event handler is ondatabinding.

· Disposed event: When a server control resource is released from memory, the corresponding event handler is ondisposed. This is the final stage of the server control lifecycle.

· Init event: when the server control is initialized, the corresponding event handler is oninit. The init event is the first step in the control lifecycle.

· Load event: This event occurs when the server control is loaded to the page object, and the corresponding event handler is onload.

· Prerender event: This event occurs after the control object is loaded and before it is rendered. The corresponding event handler is onprerender.

· Unload event: when the server control is detached from the memory, the corresponding event handler is onUnload.

The above content briefly describes several events of the control base class. Because the server controls are inherited from the control base class (webcontrol is also inherited from the control class), developers can override the event handler corresponding to the event, in this way, you can implement some custom content.

To implement custom inherited events, you need to override the protected oneventname method inherited from the base class without the need to attach the delegate (eventhandler ). Generally, the overwritten event handler should call the oneventname method of the base class to ensure that the call is attached to the event Delegate (unless you do not want to call these delegates ). The following code snippets describe the process of overwriting the inherited databinding event of a custom control.

Protected override void ondatabinding (eventargs E) { // Add 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 based on application requirements. Then, remember to call the basic class method.

The above content introduces the process of rewriting the corresponding event handler for the control-based events and derived classes. It is important to note that the preceding section does not indicate that the custom server control can only rewrite the preceding event handlers for control-based events. If custom controls inherit from other base classes with events, such as buttons and datalist (in the final analysis, they also inherit from the control base class ), the inherited event handler can still be overwritten. For example, the control inherited from the button class naturally obtains the click event, and The onclick event handler can be rewritten.

3. Create a custom Server Control event

Before introducing how to create a custom Server Control event, let's briefly review the relevant event model.

On the web forms page, events associated with server controls are triggered by the client and processed by the Web server (Note: events must be called "Events ", instead of using "Trigger" and "stimulate", they are both inaccurate and nonstandard ). For events triggered by server controls on the client, the ASP. NET 2.0 event model collects request information and uses http post to transmit detailed information to the server. The page framework on the server interprets the announcement to determine the event that occurred, and then calls the appropriate processing method. 1. This process is briefly described.

Figure 1

1. In the client computer, the user clicks the Add button in the shopping cart to try to put the selected item in the shopping cart. After clicking, the event model collects relevant information, for example, submit = btnaddtocart, prod3 = gizmo, and so on, and transmits the information to the server through post. After receiving this information, the server first analyzes it and then calls the event handler btnaddtocart (OBJ, event) for processing. The above is the basic event processing model.

For general application developers, they only need to implement the event handler of the Control. Further information is hidden for them, and there is no need to care more. However, as a server control developer, you must carefully consider this event processing model.

If you think carefully about the above process, you will find two important issues to be addressed in the event processing model. First, how does the server capture the return Click Event? Second, how does it process the data that is returned to the server through post. These two questions are crucial. If you can solve these two problems, it is very easy to create custom server control events.

To solve the preceding problems, ASP. NET 2.0 provides two important interfaces: ipostbackeventhandler and ipostbackdatahandler. The ipostbackeventhandler interface is used to process page return events triggered by the client. To implement this interface, the server control can correspond the submitted Form event of the client to the event on the server side, and process the event on the client through the event processing program. The ipostbackdatahandler interface is used to check the data submitted to the page and determine whether the data has been modified on the client. When the control implements this interface, the control automatically has the ability to participate in data return processing. Developers can implement interface-related members to complete the processing logic for the returned data.

In fact, the vast majority of server controls in ASP. NET 2.0 trigger a return from the client to the server, and many server controls implemented by the reader must also trigger a return. Therefore, the above two interfaces are very important for implementing control events. This section briefly introduces them. In the subsequent articles, the reader will take a typical example to learn more about how to implement interface members, capture callback events, and process returned data.

In addition, ASP. NET 2.0 enhances callback processing. For example, use the system. Web. UI. icallbackeventhandler interface and the page. getcallbackeventreference method. Applications of these objects can run server code on the client to avoid losing the client status and avoid overhead of server round-trip processing. These contents have some relationships with server control events. However, callback applications are rarely used in server controls. Therefore, there will be no more instructions.

　　4. Summary

From the perspective of technological development, ASP. NET has been upgraded from 1.x to version 2.0 without any significant modifications to server control event development. If you have learned about how to create a server control event under ASP. NET 1.x, you can develop the event based on the methods and ideas of 1.x in the past. In the following article, I will introduce the implementation method of server control capture callback events through typical examples.