Every time I refresh the browser, my button's event handler fires again. How do you prevent this?
One way could be to use an HTTPModule. You can generate a client side GUID, using Javascript, and have that posted back to your server. Then, if the user refreshes, you compare that GUID and see if it already exists on your server. If it does exist, then it's a refresh and you shouldn't perform your button event handler's method. An example of this implementation is described in this blog post.
Another idea could be to redirect the page (or redirect it to itself) after the user has pressed the button. This would give a clean postback and refreshing it shouldn't submit the event again.
I always try to use the PRG (Post-Redirect-Get) pattern, even though it seems a little bit unnatural to the Web Forms system.
This basically means after getting a Button_Click event, you do a redirect, perhaps using QueryString parameters to indicate to the resulting page what to display.
If you are not doing partial page updates with UpdatePanels, you don't 'lose' much doing it that way, anyway. (and if you are using partials, refreshing the page wouldn't necessarily repost anyway!)
Related
I have something like
protected void Page_Load(object sender, EventArgs e){
country.Text = "USA";
}
protected void Button_Click(object sender, EventArgs e){
Console.Write(country.Text);
}
and when the user clicks on the button, it always prints "USA", even if they wrote something else in the country TextBox, it means that Page_Load() gets fired each time a button (or any other event, I guess) is clicked.
I know how to fix this, by looking at this question, but why does that happen?
The web page is sitting on the client side web browser. When you click a button, the whole page is sent up to the server. Now you code behind can not only run, but modify controls, and does whatever you want. Once all that code is run, then the browser page is sent back down to the client.
I have often suggested that a FirstPage load event would have helped mountains here. However, over time, I think the page load having to fire each time is fine, and that the setup actually helps and promotes the fact that it runs every time. However, in desktop development - from VB6, .net, heck even delphi and C++ desktop forms? The page load even ONLY ever fires one time. So yes, it is surprise to many that web forms don't work this way. The bottom line is that page load fires every time, and the simple matter is a WHOLE NEW fresh page is sent up to the sever EVERY TIME. So, while there could have been two events, often quite a bit of page load code has to run in both cases. So then having two seperate events would cause just as much trouble.
So for code that runs first time (such as setting up the text box value)? Well, if you need that code to run each time (and you might!!!), then you place it outside of the if/then block that checks for the IsPostback. So for code to setup things such as defaults - yes, you need that code inside your IsPostBack = false block.
Web pages are what we call state-less. They are sitting on the users desktop. There is NO LIVE connection to the server. The user can close that web browser or turn off their computer. And when the user closes the browser - no information or talking is sent to the server. So you can have 2 or 2000 users typeing or editing in their brwoser - the web server does not care, see or even know that users are doing things. And the web server considers them NOT CONNECTED. They are just a web page - that page can be closed - the server does not even know the user closed the web site (there is no web page close event like desktop software). So the whole design of web pages are sate-less - and disconnneced. The web server does not know if that web page is still open, being used, or been closed. The ONLY time the web server can do ANYTHING is if you send the page back up to the server. At that point EVERYTHING in that web page starts over from scratch every post back (hence the term state-less). However, thankfully things like a text box have what is called a "view state" and they DO survive those round trips. If a control does not have a view state, then they also would lose their values on each post back. One VERY nice feature of webforms is most controls have the ability to keep their viewstate (that just means the value(s) of such controls can survive a round trip.
So when you click a button, then a whole page postback has to occur, since any code running behind would not be able to look at/ see / change the value of controls on the form. In fact, we often seen someone say run a ajax web method (in the same page) and then wonder why their code behind (in that web method) can't change controls. In fact you can write code to change controls, but it only changing the server side copy, and the copy sitting on the user's desktop is not changed. In fact, when they do (eventually) a post back, anything the code behind changed is lost.
So when you click on a button, the page load event will run FIRST and then your button code. This is how it works.
So 99% of the time, when I start typing and writing code in page load?
You do this: (say to load up a datagrid with a data table).
if IsPostBack = False then
GridView1.Datasource = myrst("SELECT * from tblhotels")
GridView1.Databind()
End if
So, you have to "assume" and "write" code that means the page load event fires every time. However, in above, we only want the first time setup code (to load up a gridview) to run one time - the first time the page loads. So now, you might have 5-6 buttons on the page, and the above code in the page load will not run since we check/test if this is a post back.
So the whole web page has to travel up to the server, else your code behind can't modify any controls or values on the web page. Once that code runs, then the page travels back down to the client side and is again just sitting on the users desktop. So clicking a button HAS to send the whole web page back to the server, else the values of controls on the web page could not be modified, and worse the results of that code would never be displayed back in the browser. So code behind can't JUST modify one control. it needs a whole copy fo the web page first, and then you can change a control (or several) and then the whole page makes the trip back to the browser. So you can't write code to JUST change one control without first having a WHOLE copy of the web page with everything. However, you can use what is called a update panel. This will allow you to run code that updates JUST part of the page. However, even in that case, the page post back event does run first - this is often called a partial page post back. So you can drop in a update panel, and have buttons and code in that update panel - they can only modify things inside of that update panel, but you note that the whole page does not replot or re-fresh. You can also hand code JavaScript ajax calls, and they can client side modify some controls (and even call routines server side). But you still have to assume that code behind can NOT see + use those controls until such time the web page travels up to the server. This applies even when using a up-date panel (the code behind can only modify controls in the update panel). Update panels are very nice in that you don't have to wire up and hand code a whole bunch of ajax and JavaScript to allow partial updates of the web page and not have to cause a full page post back. But as noted, even when using a up-date panel, the page load event does fire. So for the most part, you in general write the page load and setup code inside of that postback=false code block.
This is what the ASP.Net Button class tells us about the Button class:
By default, a Button control is a Submit button. A Submit button does
not have a command name (specified by the CommandName property)
associated with the button and simply posts the Web page back to the
server.You can provide an event handler for the Click event to
programmatically control the actions performed when the Submit button
is clicked.
I have page with some asp.NET form stuff on it, including drop down lists and a calendar.
I had trouble with stuff being NULL, so I tried putting in a breakpoint in my constructor. It stopped at the breakpoint before the page first loaded as it should. Then I stepped past it and the page loaded. I then chose a date in the calendar and it stopped at my breakpoint.
I don't use the event of date chosen for anything. Actually, my page only uses the event when the button on it is clicked. But somehow, it looks like my constructor is called at all events.
Is this true? How can this be true? Does it make an entirely new instance of the page at each event fired?
Yes, it is normal for a new instance of your page to be created for all postbacks. The alternative would be to keep the server-side object around for as long as the user's session persists, even though the server has no way of knowing whether the user is even still looking at the page. Since that is undesirable, an alternative approach is needed: pages get destroyed and re-created between each request.
Some controls, including indeed calendar controls, will automatically cause postbacks, in order to (e.g.) show the proper days of the month after the user has selected a different month. Other controls don't cause such postbacks, either because they don't need new server-generated information at all, or because they use other methods to contact the server. The control's documentation should tell you so, and how (if at all) that behaviour can be controlled.
I am trying to implement a KeyDown event for a textbox in Visual Web Developer. I am using C#. I know how to do this in a windows form but the technique isn't portable to VWD. I want to capture the text in the textbox when the user hits Enter.
Any advice is appreciated.
Regards.
Sounds like you may want to read up a bit on Web forms in general. A quick summary:
Since web pages are all client side, you have to explicitly tell it when to talk to the server where all the major lifting takes place.
So you have the html form tags:
<form>
</form>
and all important text boxes and other form controls go between.
Then you need a submit button which under normal circumstances is the only way to submit the form to the server for processing. (The "enter" key activates the submit key also.). Submission always either reloads the page or causes a move to the next page, depending on the actions specified.
ASP.NET does take care of a lot of page events and such for you. as you have probably noticed by now, though, when you right click a text box and look at the available events, you only have a few, such as "textchanged". This is because anytime you do not actually submit a form to the server, you need AJAX to do a call to the server for you while not reloading the page. the "textchanged" event on a textbox is still going to be AJAX driven - it's just the Microsoft has built it in for you. You will want to look at either jQuery or the ASP.Net AJAX libraries.
You say you want to "store" the result - is it to generate new behavior later on the page? that's AJAX. Is it for longevity while the entire application is worked through? That can wait until the submit.
Actually the textChanged method waits for the Enter key to be hit.
I have a simple three page asp.net webforms site and having an issue with the back browser button that throws the popup "...Firefox must send any information that will repeat any action.." when hitting back on the step3.aspx.
The flow is: user lands on step1.aspx, session starts, and a user quotes on a product and gets redirected to step2.aspx. On step2.aspx, you confirm the purchase by clicking an asp:Button. The OnClick event handler, btnPurchase_Click, handles the logic for purchase and redirects, Response.Redirect("step3.aspx"), to step3.aspx. Step3.aspx simply displays the confirmation page (receipt details). The session is destroyed on step3 and when the user hits the back browser button, they are prompted with the resubmit post popup. Ideally, I want the user to hit step1 on hitting back without the resubmit prompt. Each page is set to no-cache and redirects to step1 if session is invalid.
Does anyone have a suggestion for a better flow?
This site will eventually be migrated to asp.net mvc/ajax which will most likely make the PRG workflow easier to implement but for now, looking for a relatively simple way.
A simple solution is to never allow a page to render on postback, but instead accept/store whatever information it was posted, and then redirect to the next page (or itself).
That way if a user hits the back button, it is going back to a GET, not a POST, and avoids the popup.
I give this question a try. The flow you mention will obstruct the pages normal function, which you of course already have in mind. Though, i would say it can be dangerous (against the function you expect) and contraproductive. Based on what I can see from your question, I would definitively remove Page2 and Page3 and keep all logic in same and single page.
I would also be happy to hear what you are trying to avoid, with this? Is it double posts? Like a double-post of a content in a shopping cart? Partial / uncomplete inserts of data input? With the described way to affect back-buttons, you may come around one problem but rise another. A big range of browsers that can act completely different on such work-arounds.
I see two good options,
UserControl,
Create three UserControls which every each of them have each page specific logic. You can programmatically load them into the page. I.e. on bnButton_Click Event. Usercontrols are loaded with LoadControl("PathToAscxFileOnDisk.ascx").
Panels,
I would also think about three <asp:PlaceHolder></asp:PlaceHolder> or perhaps better <asp:Panel></asp:Panel> to put all logic into.
In this case you are completely free from the postback issues and can focus on moving your functions into business logic and have use the Code-File to control the flow on show/hide and populate the controls in/out from the panels/usercontrols. You can probably also control the postback / click-URL & push-enter-key.
And you mentioned Ajax,
Ajax is absolutely there to make your page stateless (which means you can work without cache, sessions, viewstate and so on. Though, the problem lies in the users possibility to navigate between pages. I would think even Ajax is of less help, while you keep the three-pages-solution.
I would personally say it is a simple task to move the aspx files into each ascx and create a aspx as a master-container. With that option you even avoid duplicate namings (like if you copy / paste the code into panels) and trouble with Page_Load flow/logic.
If I understand correctly you're not yet using the PRG.
On step 2, temporarily store the information and redirect to show it. How you do so depends a lot on your application: session, database, cookies, etc are all options with different caracteristics.
Then redirect to show that information.
Same goes on step 3.
If you hit back on step 3, you'll go to step 2. But given you're going back to a GET request, there won't be a warning. Like you said, your application destroys the session data on 3, so according to what you said the user would go to step3.
Maybe I'm missing something on what you said.
This is probably a simple question for every WebForms developer but I am knew to this scene. I have a page that has an "ADD" button on it that results in a jquery popup where the user can submit a form that will add an entry to the repeater on the page. My problem is that after the user adds an item, if they then hit the refresh button the item will get added again. I can't stop this with the page.ispostback because that would block the original add. What can I do here?
that's a common problem. Here's explanation and solution of the problem.
When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.
To avoid this problem, many web developers use the PRG(Post/Redirect/Get) pattern.
copied from wiki (LINK)
simplest solution can be Response.Redirect to the same page (i.e. if you page is named default.aspx write Response.Redirect("default.aspx")). if you do this browser refresh button will just load the page as if you have typed in address bar URL and navigated to it.
here's SO question How to stop unwanted postback that might be useful as well.
If there is an option to delete an item on the page (is there?), do you really have to be concerned with that happening? May want to think about that. Just a thought.