Well this Article explains you how we can post back the one page values. Before going to this .Let's first understand what will happen while the page is post back to the server. Think that someone requests an ASP.NET Web page (.aspx file), as soon as the request will be sent to the server and the page runs as a program on the Web server. While the page is running, it can perform any task that your Web site requires, including calculating values, reading or writing database information, or calling other programs. As its output, the page dynamically produces markup (elements in HTML or another markup language) and sends this dynamic output to the browser. This we can call as Round Trip or Post back.
The processing cycle for an ASP.NET Web page is this:
1. The user requests the page. (The page is requested using an HTTP GET method.) The page runs for the first time, performing preliminary processing if you have programmed it to do so.
2. The page dynamically renders markup to the browser, which the user sees as a Web page similar to any other page.
3. The user types information or selects from available choices and then clicks a button. (If users click a link instead of a button, the page might simply navigate to another page, and no further processing takes place on the first page.)
4. The page is posted to the Web server. (The browser performs an HTTP POST method, which in ASP.NET is referred to as a postback.) Specifically, the page is posted back to itself. For example, if the user is working with the page Default.aspx, clicking a button on the page posts the page back to the server with a target of Default.aspx.
5. On the Web server, the page runs again. The information that the user typed or selected is available to the page.
6. The page performs the processing that you have programmed it to do.
7. The page renders itself back to the browser.
This cycle continues as long as the user is working in the page. Each time the user clicks a button, the information in the page is posted to the Web server and the page runs again. Each cycle is referred to as a round trip. Because page processing occurs on the Web server, each action that the page can do requires a round trip to the server.
Under some circumstances, you might want a page to post to a different page, not to itself. This is referred to as cross-page posting. For example, you might be creating a series of pages that process a customer order. Each page can post to the next page in the sequence. In that case, you can configure certain controls (like Button control) on the page to post to a different target page.
Cross-page posting provides some advantages over using the Transfer method to redirect 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.
Let's see how we can do this Cross Page post backing in Two methods, it up to you to use your convenient method:
Method 1:
This is enabled by a button on the first page setting PostBackUrl property to the page that will handle the postback. Once in the second page you can access the controls from the previous page by accessing the Page.PreviousPage property. Here's a sample that's like most of the documentation I've seen:
// Page1.aspx
<form id="form1" runat="server">
<div>
First Name :<asp:TextBox ID="Fname" runat="server"></asp:TextBox><br />
Last Name :<asp:TextBox ID="Lname" runat="server"></asp:TextBox>
<asp:Button ID="btnGo" runat="server" Text="Leave Me" PostBackUrl="~/CrossPostBack/page2.aspx" />
</div>
</form>
// Page2.aspx
<form id="form1" runat="server">
<div>
<h1> Hi ...<asp:Label ID="lblName" runat="server" Text="Label"></asp:Label> !!!!
</h1>
<p> Welcome To New Page..........
<a href="Page1.aspx">Click Here</a> To GoBack..</p>
</div>
</form>
In Code Behind Method:
protected void Page_Load(object sender, EventArgs e)
{
TextBox txtFname = (TextBox)PreviousPage.FindControl("Fname");
TextBox txtLname = (TextBox)PreviousPage.FindControl("Lname");
lblName.Text = txtFname.Text + " " + txtLname.Text;
}
I find this to be entirely too tedious primarily because this approach still loses out of the declarative server side object model. The second page has to re-declare the same controls as local variables to access the properties. I don't think it will be how people write their second page to handle the post back. Instead the more useful approach will be to use the <%@ PreviousPageType %> directive in the second page:
Method 2:
// Page1.aspx
Add the Public Variable to access it in new page.
<script runat="server">
public string Sum
{
get
{
string result=Fname.Text + Lname.Text;
return result;
}
}
</script>
<form id="form1" runat="server">
<div>
First Name :<asp:TextBox ID="Fname" runat="server"></asp:TextBox><br />
Last Name :<asp:TextBox ID="Lname" runat="server"></asp:TextBox>
<asp:Button ID="btnGo" runat="server" Text="Leave Me" PostBackUrl="~/CrossPostBack/page2.aspx" />
</div>
</form>
// Page2.aspx
<%@ PreviousPageType VirtualPath="~/CrossPostBack/Page1.aspx" %>
<div>
<h1> Hi ...<asp:Label ID="lblName" runat="server" Text="Label"></asp:Label> !!!!
</h1>
<p> Welcome To New Page..........
<a href="Page1.aspx">Click Here</a> To GoBack..</p>
</div>
In Code behind :
protected void Page_Load(object sender, EventArgs e)
{
lblName.Text = PreviousPage.Sum.ToString();
}
The first page utilizes the posted data via the declarative controls and it provides the necessary information to the second page a public property. Now this is much better since we now get to reuse the declarative controls. I really think this will be the preferred style of using cross page postbacks in ASP.NET 2.0.
One very interesting thing I've noticed about cross page postbacks is the life cycle of the first page when posting back to the second. The first time the second page accesses Page.PreviousPage ASP.NET needs to make a page object available. So it, in essence, creates the Page.PreviousPage object and calls ProcessChildRequest , which is similar to ProcessRequest except it stops processing prior to PreRender and a fake Response object is created so that no Write s are emitted. This has some interesting side effects, one of which is that all of the server side events of the first page fire. This includes Page_Init , Page_Load and any control events like Button.Click events (if the Button has an OnClick event declared). This blew me away and it's certainly something to keep in mind when using cross page postbacks. One way to detect if your page is being accessed as a PreviousPage is to check Page.IsCrossPagePostBack .
One last thing to note about cross page postbacks is that, the PreviousPage's Trace messages end up mixed with the current page's Trace messages.
