On my asp.net c# page I have two text boxes(start and end dates) with ajax CalendarExtenders. The user selects a start date and then an end date. On selecting the end date, I bind my grid as shown below;
protected void calEndDate_TextChanged(object sender, EventArgs e)
{
BindGrid();
}
In the grid I have a command button with the following code
protected void gvAllRoomStatus_RowCommand(object sender, GridViewCommandEventArgs e)
{
if (e.CommandName == "Manage")
{
GridViewRow row = gvAllRoomStatus.Rows[Convert.ToInt16(e.CommandArgument)];
int BookingID = Convert.ToInt32(row.Cells[1].Text);
DataClassesDataContext context = new DataClassesDataContext();
Session["BookingID"] = BookingID;
Response.Redirect("CheckIn.aspx");
}
}
When the user goes to that page and clicks the back button all the selected dates and the gridview data disappears. Any ideas why the viewstate is disappearing?
ViewState belongs to the current Page.
Have a look: http://www.codeproject.com/Articles/37753/Access-ViewState-Across-Pages
Yes, we can access the viewstate variables across pages. This is only
possible if Cross Page Posting or Server.transfer is used to redirect
the user to other page. If Response.redirect is used, then ViewState
cannot be accessed across pages.
So you could use Server.Transfer instead or use the Session.
Viewstate to look at it in a very simplified way is to see it as a carbon copy or cache of the last state of the page you are currently on. Therefore doing a redirect to any page, even the same page itself, is essentially a fresh start. The viewstate no longer applies as for all intent and purpose, you are on a new page.
As Tim suggests in his post, either store the required data as a session variable or use a server.transfer.
Take a look here for a nice overview of viewstate:
http://www.codeproject.com/Articles/37753/Access-ViewState-Across-Pages
In my opinion the issue you have is because you make auto post backs with calEndDate_TextChanged using Ajax.
After your submit, when you press the back button the browser can not remember neither can save what you have change with all that auto post data with Ajax calls, and you lose them.
For me remove the Text Change auto post back, remove the Ajax because you do not needed and make a regular full post back when the user submit their data.
Then when you make back with the browser, browser load the previous state and most of the browsers remember what and all the input of the user. Also on that back the viewstate is the same as previous because did not have change from the Ajax.
Related
I'm working with ASP.NET webforms and I'm wondering if it is possible to change/ignore the PostBackUrl so it won't change pages.
My button:
<asp:Button ID="continuebtn" OnClick="Continuebtn_Click" runat="server" PostBackUrl="~/client/profile.aspx" CssClass="btn btn-success btn-sm" Text="Continue"/>
And the OnClick function is:
protected void Continuebtn_Click(object sender, EventArgs e)
{
//some code
if(condition == false)
//change the url from PostBackUrl so it won't change pages
else
//keep the current Url
}
I've tried :
continuebtn.PostBackUrl = "";
continuebtn.Attributes["PostBackUrl"] = "return false";
continuebtn.Attributes.Remove("OnClick");
continuebtn.Attributes.Add("OnClick","return false");
continuebtn.OnClientClick = "return false;";
add return; to if
I tried to remove the PostBackUrl from the button and add it from the code behind with continuebtn.PostBackUrl = "~/client/profile.aspx" but it didn't work either.
There are two big reasons to use post-back URL in place of say using a code behind click event and say then response.Redirect("some web page").
First up, post-back url passes the previous page!!!!!
So, if you have say a text box and a button like this: (or evne a grid view)
Now you can use code behind to jump to the next page, or you can use/set/have post-back url set.
If you use post-back URL. Then you don't need to write a code behind stub, and you ALSO get use of previous page in the next page on-load event (you ONLY can pick up previous page in load - first time).
eg:
protected void Page_Load(object sender, System.EventArgs e)
{
if (IsPostBack == false)
{
TextBox tbox;
tbox = Page.PreviousPage.FindControl("TextBox1");
Debug.Print("Text box = " + tbox.Text);
TextBox1.Text = s;
}
}
}
so post-back url = a great way to pass/get at/use the previous page values with find control. Now if you not needing to do this, then you probably should not use post-back URL, since you are bulking up the payload for the next page (it will contain the current page, and you have as noted use of "previous page". However, it is a fantastic way to avoid parameters and/or cluttering up session() just to pass a bunch of values. Just use post-back URL and then like "magic" then previous page can be used. if you don't use post-back URL then previous page is null and not valid.
And if you place two buttons on the page? Can you set postback url? Sure you can set that control, text box or do anything you like - but do keep in mind that the code behind is running AFTER a post-back, and it will of course be too late to change a button that CAUSED the post back.
So, you can certainly do this in button2 click even to change button1:
protected void Button3_Click(object sender, EventArgs e)
{
Button1.PostBackUrl = "";
}
So in above, button3 click event and code behind wiped out the post-back URL of button one. Or we can of course set the url to anything we want.
Now, the code behind is done, page is rendered and THEN sent back down to the browser with the above change. If user hits button1, then no postback url exists - we blew it out with the above code.
However, in the SAME button event? no, it is too late to change or modify the post-back.
In that case, and if you need "conditional" jump? Then you need to delete and remove the post-back url, and simply put the logic you need to determine the ya, or nay jump based on the code behind for that click event.
HOWEVER - and a BIG WHOPPER however? If you JUST use a response.Redirect("some web page") in that code behind, then you DROPPIGN THE MAIN reason as to why the developer used post-back URL in the first place. That main, big, huge, large reason is that post-back URL gives the next page in line FULL USE of the previous page values with "previous page". If you do NOT use post-back URL, then you can't use previous page to pass all those values and inspect and get and grab control values from the previous page.
So what if you really did need the "abilities" that post-back URL provides (that ability of course is "previous" page in the next page load!
In that case, then you have to use Server.Transfer() in that code stub to get use of previous page in the next page that loads.
So, regardless:
You can't change post-back URL in the same button code event - it is too late.
If you are going to then put the logic in the code event? Then be VERY VERY aware that if you use a response.Redirect("some web page"), then you may VERY well be breaking the functionally of why in the first place the developer used post-back url (to have use of "previous page".
Your suggested idea to modify client side the post-back url in one button click, and then do a js "click" of that button you just changed the post-back url should also work (good idea!!!).
But, I would thing that just using a code behind stub in the click event, and then the code can choose to navagate or jump to the next page based on that code? Right?
However, if you do that, then you will break the "features" of post-back URL in pasing page prevous.
In that case? Then you need to use a server.Transfer("to next web page") in place of response.Redirect("to next web page), since a server.Transfer will give you use of "page previous" in the next page load event JUST LIKE post-back URL does!
Of course with a server.Transfer, you will note that the web page URL does not change or update - and this is a fall out of having to do this. (and may, or may not matter to you).
I've got a 'menu' within a Master page which includes a number of image buttons with click events.
Within each click event, I want to redirect the user to a specific (Child) page. However, if the user is already on the correct (Child) page, I don't want to refresh the page and lose the entered data.
In the example below, I want to redirect the user to browse.aspx however, if the user is already on browse.aspx, I don't want to refresh it.
Is there a better way to do this than the following?
protected void ibtnBrowse_Click(object sender, ImageClickEventArgs e)
{
if (!Request.Url.Segments[1].ToString().Equals("browse.aspx"))
{
Response.Redirect("~/browse.aspx");
}
}
How about disabling the Image button on the page?
e.g.
When you are on browse.aspx, in code behind browse.aspx.cs you can disable the button.
ImageButton iBtn = (ImageButton)Page.Master.FindControl("ibtnBrowse");
iBtn.Enabled = false;
By having server side click events the page will always "refresh" when clicking on these buttons. However, if you are simply looking to avoid doing an unnecessary redirect in your code you can use:
HttpContext.Current.Request.Url.AbsoluteUri
or
HttpContext.Current.Request.Url.AbsolutePath
If you decide to use javascript to switch between pages you can use location:
location.replace("http://www.w3schools.com");
location.assign("http://www.w3schools.com");
I am working on a page in ASP.NET/C# where the user's information is saved to the database.
There are many fields on the page and when the validations are done then the information is saved.
The submission of information is done using an ASP.NET button.
The primary key of the table is generated in code itself, that is, every time it is increased by one.
I just faced an issue while reloading the page through the browser's reload button. I noticed that the same user information was submitted with the primary key value incremented by one.
So my question is how should I tackle this issue?
Should I just clear values of all textboxes after successful submission of data so that it will validate and then the user has to fill the information again?
Please share your ideas as to how can I handle this.
The easiest thing to do use use the Post/Redirect/Get pattern, where after a postback where you have inserted the row, you redirect the user back to a page where they can view the item. This way, if they press Refresh, it will just refresh the view page.
For example:
protected void Button1_Click(object sender, EventArgs e)
{
// Insert Data
...
// Redirect to get
Response.Redirect("ViewItem.aspx?id=" + insertedItemId);
}
NB: They can still press back and submit again, but this is usually confirmed by the browser before resubmitting.
I googled this about 1/2 a hour no hit's. Scenario is that, dynamic scripts are saved in string builder whose "string" representation is stored in session. It just happens that when user navigates away from one page to another the script[from session] gets registered using "RegisterStartupScript". The script is registered in PreRender event of the Page. So i would like to clear this script in session while the page navigates away btw rule out a option to create another session variable and clear previous one. It's a overhead :(
Why are you storing this in Session, do you need to maintain this script in between GET requests?
If only postbacks are relevant you could store it in viewstate as this is maintained only when doing a postback.
If you want this string to be available on GET requests too you might want to introduce a different variable which has an identifier identifying the page for which the script is generated. If the requested page doesn't match the control variable you will have to generate a new script.
How is the user navigating away from the page? Can't you use an ASP.NET button instead of a hyperlink, and then do a Redirect in code once you have cleared your session variable?
protected void btnDoSomething_Click(object sender, EventArgs e)
{
Session["Value"] = String.Empty;
Response.Redirect(strURL, false);
}
OR You could add a variable in the query string and check it in the Page_Load event of the target page:
Webform1.aspx?reset=true
Since I cant comment yet, use onUnload().
It fires on full postbacks too. Ajax postbacks dont fire!
What you need to do, is guaranty inside the onUload function that you only clear the session when you want. Like setting a variable isPostBack to true before the postbacks so onUnload sees the variable and doenst send a request to clear the session.
You may use the JavaScript onUnload() and call an AJAX service, that will clear the server side session.
I have a text string value that I'd like to persist from one web page to another without using query strings or the session/view states. I've been trying to get the ASP http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.hiddenfield.aspx">HiddenField control to pass information from one web form to a different form.
All the hiddenfield control examples that I've seen is to preserve round trips from the client to the server for the same form.
Is there way for a form to access the ASP controls (and their values) from the previously-rendered form? Or is the initial form simply disposed of in memory by the time the second form executes it's OnLoad method?
Quick answer is no. As others have noted, you can use Server.Transfer and then you can - however this is to be used with caution. It is a "server side redirect" eg.
Your user is on http://mysite.com/Page1.aspx they click a button and you perform a Server.Transfer("Page2.aspx"). Page2.aspx will be rendered in their browser, but the URL will still be Page1.aspx, this can cause confusion and mess up back/forward navigation.
Personally I would only use Server.Transfer as a last resort - in the world of the web, sharing data across pages generally means you need to use a storage mechanism; Cookie, QueryString, Session, Database - take your pick.
You can't get the previous page fields with Response.Redirect.
You can with cross page posting :
if (Page.PreviousPage != null)
{
TextBox SourceTextBox =
(TextBox)Page.PreviousPage.FindControl("TextBox1");
if (SourceTextBox != null)
{
Label1.Text = SourceTextBox.Text;
}
}
If both pages live in the same application you can use Server.Transfer:
firstpage.aspx:
protected void Page_Load(object sender, EventArgs e)
{
Server.Transfer("~/secondpage.aspx");
}
secondpage.aspx:
protected void Page_Load(object sender, EventArgs e)
{
Page previousPage = (Page) HttpContext.Current.PreviousHandler;
Label previousPageControl = (Label) previousPage.FindControl("theLabel");
label.Text =previousPageControl.Text;
}
A somewhat better solution would be implementing an interface on your first page where you expose properties for the values needed by the second page.
I would presume that the Response.Redirect() sends a Location: HTTP header to do a redirect.
As HTTP is stateless, I'd also presume that these variables are inaccessible.
There are however, solutions.
Print a form with hidden fields, and use javascript to submit it
Redirect in the code internally (load up the thing it needs to get to manually)
Store the data in some temporary database table somewhere, and pass along a unique ID
However, from my experience, I can't understand why you might need to do this (other than re-submitting a form after a user authentication - which hopefully you should be able to use method 2 for
Remember, a Response.Redirect instructs the browser to issue another request to the server. So far as the server is concerned, this next request is indistinguishable from any other incoming request. It's certainly not connected to a previous form in any way.
Could you explain your aversion to storage in the session, so we can propose some viable alternatives?