Cross-Page Posting in ASP.NET Web Pages
By default, buttons and other controls that cause a postback on an ASP.NET Web page submit the page back to itself. This is part of the round-trip cycle that ASP.NET Web pages go through as part of their normal processing. For details, see Introduction to ASP.NET Web Pages.
Under some circumstances, you might want to post one page to another page. For example, you might be creating a multi-page form that collects different information on each page. In that case, you can configure certain controls (those that implement the IButtonControl interface, such as the Button control) on the page to post to a different target page. This is referred to as cross-page posting. Cross-page posting provides some advantages over using the Transfer method to redirect to another page. For details, see Redirecting Users to Another Page.
Because cross-page posting is configured for individual controls, you can create a page that posts to different pages depending on which button the user clicks.
When you configure a page for cross-page posting, you frequently want to get information from the source page. This might include the information from controls on the page—that is, the information being posted by the browser—as well as public properties of the source page.
Getting Control Values
The Page class exposes a property named PreviousPage. If the source page and target page are in the same ASP.NET application, the PreviousPage property in the target page contains a reference to the source page. (If the page is not the target of a cross-page posting, or if the pages are in different applications, the PreviousPage property is not initialized.) By default, the PreviousPage property is typed as Page.
If the source and target page are in different applications, you cannot directly get the values of controls on the page, but you can read the posted data from the Form dictionary. You cannot read view state from the source page, because it is hashed. If you want to store values in the source page and make them available in a target page in another application, you can store the values as strings inside hidden fields on the source page and access them through Request.Form on the target page.
If you are coding the source page specifically to be able to share information with target pages, an easier way to make control values available to the target page is to expose them as public properties. For details, see Getting Public Property Values from the Source Page later in this topic.
The following code example shows how you can get the value of the TextBox1 control on the source page.
If Not Page.PreviousPage Is Nothing Then Dim SourceTextBox As TextBox SourceTextBox = CType(PreviousPage.FindControl("TextBox1"), _ TextBox) If Not SourceTextBox Is Nothing Then Label1.Text = SourceTextBox.Text End If End If
The FindControl method finds controls in the current naming container. If the control you are looking for is inside another control (typically, inside a template), you must first get a reference to the container and then search the container to find the control you want to get. In the following code example, the source page contains a Login control with a LayoutTemplate container that in turn contains a TextBox control named UserName. The code gets the value of the UserName control.
Dim LoginControl As Login LoginControl = CType(PreviousPage.FindControl("Login1"), Login) If Not LoginControl Is Nothing Then Dim UserName As TextBox UserName = CType(LoginControl.FindControl("UserName"), TextBox) If Not UserName Is Nothing Then Label1.Text = UserName.Text End If Else Label1.Text = "Cannot find user name in Login control." End If
Getting Public Property Values from the Source Page
In the target page of a cross-page posting, you can also get the values of public members of the source page. The most common scenario is that the source page defines public properties and you want to get their values on the target page.
It is recommended that you expose only the information you need as public properties to reduce the amount of information available to potentially malicious users.
To get public members of the source page, you must first get a strongly typed reference to the source page.
You can do so in a number of ways. The first is to include an @ PreviousPageType directive in the target page, which allows you to specify the source page, as in this example:
<%@ PreviousPageType VirtualPath="~/SourcePage.aspx" %>
When this directive is included, the PreviousPage property is strongly typed to the class of the referenced source page. As a consequence, you can directly reference public members of the source page. You can specify the type of the source page either directly, using a type attribute, or indirectly by explicitly referencing the source page in a VirtualPath attribute, as shown in the example.
The following code example shows a portion of a source page containing a public property named CurrentCity that exposes the value of a TextBox control named textCity.
Public ReadOnly Property CurrentCity() As String Get Return textCity.Text End Get End Property
Properties on the source page that are created primarily to expose values for cross-page posting are usually read-only properties. Although the source page can contain public read/write properties, setting a source page property from the target page property generally has no purpose, because the value will not be persisted.
If the target page contains a PreviousPageType directive that points to the source page, you can access the source page's CurrentCity property using code such as the following.
Another way to get a strongly typed reference to the source page is to include an @ Reference directive in the target page that references the source page, as you would reference any type that you wanted to use in your page. In that case, in the target page you can get the target page's PreviousPage property and cast it to the source page type, as in the following code example.
Checking for Postbacks in the Target Page
During a cross-page postback, the contents of the source page's controls are posted to the target page, and the browser executes an HTTP POST operation (not a GET operation). However, in the target page, the IsPostBack property is false immediately after a cross-page post. Although the behavior is that of a POST, the cross-posting is not a postback to the target page. Therefore, IsPostBack is set to false and the target page can go through its first-time code.
If it is useful in your application, you can determine whether the target page is running as the result of a cross-page post. To do so, you can test the IsCrossPagePostBack property of the page reference returned by the target page's PreviousPage property, as in the following code example.
If PreviousPage IsNot Nothing Then If PreviousPage.IsCrossPagePostBack = True Then Label1.Text = "Cross-page post." End If Else Label1.Text = "Not a cross-page post." End If
Note that if the current page is not the target of a cross-page post, the PreviousPage property returns null (Nothing in Visual Basic).
For more information, see How to: Determine How ASP.NET Web Pages Were Invoked.
Cross-Page Posting versus Server.Transfer
The PreviousPage property and the PreviousPageType directive are useful in two situations where you invoke the target page: in a cross-page postback, which is a client-based transfer, and with the Transfer method, which is a server-based operation. In both operations, code in the target page can get a reference to the source page using the PreviousPage property.
It might be important in the target page to determine whether the page was invoked from a cross-page posting or a Server.Transfer operation. To help you do this, the Page class exposes a property named IsCrossPagePostBack. For details, see How to: Determine How ASP.NET Web Pages Were Invoked.