C#城市公交查询系统(文献综述+外文文献翻译+源程序) 第3页
A page that wants to handle a certain event should explicitly register an appropriate handler. However, for backward compatibility with the earlier Visual Basic programming style, ASP.NET also supports a form of implicit event hooking. By default, the page tries to match special method names with events; if a match is found, the method is considered a handler for the event. ASP.NET provides special recognition of six method names. They are Page_Init, Page_Load, Page_DataBind, Page_PreRender, and Page_Unload. These methods are treated as handlers for the corresponding events exposed by the Page class. The HTTP run time will automatically bind these methods to page events saving developers from having to write the necessary glue code. For example, the method named Page_Load is wired to the page's Load event as if the following code was written.
this.Load += new EventHandler(this.Page_Load);
The automatic recognition of special names is a behavior under the control of the AutoEventWireup attribute of the @Page directive. If the attribute is set to false, any applications that wish to handle an event need to connect explicitly to the page event. Pages that don't use automatic event wire-up will get a slight performance boost by not having(51-aspx) to do the extra work of matching names and events. You should note that all Microsoft Visual Studio® .NET projects are created with the AutoEventWireup attribute disabled. However, the default setting for the attribute is true, meaning that methods such as Page_Load are recognized and bound to the associated event.
The execution of a page consists of a sequence of stages listed in the following table and is characterized by application-level events and/or protected, overridable methods.
Table 1. Key events in the life of an ASP.NET page
Stage Page Event Overridable method
Page initialization Init
View stateloading LoadViewState
Postback data processing LoadPostData method in any control that implements the IPostBackDataHandler interface
Page loading Load
Postback change notification Raise51PosAspxtDataChangedEvent method in any control that implements the IPostBackDataHandler interface
Postback event handling Any postback event defined by controls RaisePostBackEvent method in any control that implements the IPostBackEventHandler interface
Page pre-rendering phase PreRender
View state saving SaveViewState
Page rendering Render
Page unloading Unload
Some of the stages listed above are not visible at the page level and affect only authors of server controls and developers who happen to create a class derived from Page. Init, Load, PreRender, Unload, plus all postback events defined by
www.youerw.com control tree has been successfully created. In other words, when the Init event arrives, all the controls statically declared in the .aspx source file have been instantiated and hold their default values. Controls can hook up the Init event to initialize any settings that will be needed during the lifetime of the incoming Web request. For example, at this time controls can load external template files or set up the handler for the events. You should notice that no view state information is available for use yet.
Immediately after initialization, the page framework loads the view state for the page. The view state is a collection of name/value pairs, where controls and the page itself store any information that must be persistent across Web requests. The view state represents the call context of the page. Typically, it contains the state of the controls the last time the page was processed on the server. The view state is empty the first time the page is requested in the session. By default, the view state is stored in a hidden field silently added to the page. The name of this field is __VIEWSTATE. By overriding the LoadViewState method—a protected overridable method on the Control class—component developers can control how the view state is restored and how its contents are mapped to the internal state.
Methods like LoadPageStateFromPersistenceMedium and its counterpart SavePageStateToPersistenceMedium can be used to load and save the view state to an alternative storage medium—for example, Session, databases, or a server-side file. Unlike LoadViewState, the aforementioned methods are available only in classes derived from Page.
Once the view state has been restored, the controls in the page tree are in the same state they were the last time the page was rendered to the browser. The next step consists of updating their state to incorporate client-side changes. The postback data-processing stage gives controls a chance to update their state so that it accurately reflects the state of the corresponding HTML element on the client. For example, a server TextBox control has its HTML counterpart in an <input type=text> element. In the postback data stage, the TextBox control will retrieve the current value of <input> tag and use it to refresh its internal state. Each control is responsible for extracting values from posted data and updating some of its properties. The TextBox control will update its Text property whereas the CheckBox control will refresh its Checked property. The match between a server control and a HTML element is found on
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
C#城市公交查询系统(文献综述+外文文献翻译+源程序) 第3页下载如图片无法显示或论文不完整，请联系qq752018766
