I have inherited textbox and dropdownlist controls in C# and added some custom logic to them for setting background and all in C#
I am adding them to my user control(ascx) and using this usercontrol in aspx page. But On postback I lose values for all textboxes dropdown etc.
Can anyone help.
That's just the way it works, and it's worse than you think. It's not that your control is losing it's data. It's that it's not even same instance of the control any more.
In ASP.Net, you work with a completely new instance of your page class, including any controls in the class, on every postback. There is a page lifecycle you need to understand before you'll be able to do much, but the summary goes like this:
User sends an http request for a page via the browser
ASP.Net runtime in IIS creates an instance of the page and calls methods like Pre_Init, Load, Render, etc in a specific order.
The result of this process is then used to send an http response to the user's browser with the rendered html.
Once the response is sent, the page class instance is disposed and destroyed. It no longer exists.
The browser receives the http response and renders the page for the user.
If the user does anything that causes a postback, the entire process starts again. It's a whole new http request, a whole new page class, and a whole new http response. Things like calling the page's Load method are repeated. Also note the order for steps 4 and 5. Due to latency between the browser and web server, it's common that the page class is already destroyed before the response even reaches the user. By the time the user sees a page, the class instance that produced the page is already long gone.
To get around this, you need to put data that should persist across requests into a storage location that will actually persist, such as ViewState or the Session.
Related
I've got an Asp.net MVC action that creates user account(after input validation). And a View containing registration form that invokes this action. While action validates input, user is left with webbrowser waiting for server response and click submit button a few more times. This creates several accounts. Is there a way to prvent user from form resubmition without javascript. I cannot use javascript in this project it is intended for non javascript browsers. Or can you suggest(server) other solution?
EDIT:
This form request use POST method
JavaScript is not allowed because this Web Application is aimed for special web browsers for people with disabilities that do not support javascript
You have to handle the situation on the server-side then, there's no way around that.
There are 3 options that come to my mind atm:
create a cookie and for each submit check if it exists
similar, but using a session object
before creating a new account, always check if the user exists in the database. THIS should be a no-brainer anyway!
You can add a unique hidden token as part of the form. This token can also be saved as part of the session on the server.
When the user posts the form on the first action, the token is validated and a flag set to indicate the request is being processed. The action processed and results presented. If, while awaiting results, the user attempts to repost the request, the token validation fails as the request is still being processed.
On a side node, the main reason people continuously click is that there is no feed back on whether the request was received by the server or not. To this affect, it might be better to redirect the user to an interim page that shows the request is being processed. Which in conjunction with the above can be used to show the request progress and redirect to the appropriate page when completed.
Of-course, you should also consider making the process a bit lighter. So, that the system can respond quickly to input rather than making the user wait.
Is it a requirement to use MVC? I think you can accomplish something similar using WebForms. When the user submit the request, in the code behind you can disabled the submit button like this:
btnSubmit.Enabled = false;
But if MVC is a must be, #walther answer would be correct
Is it possible to have results from another page returned to a JavaScript method or a C# controller action?
I have a shared complex page that's used all over my website that's currently used to set a single variable on the user data in the C# back end. When the user has finished the shared complex page, I return to the referring page. The page that I've returned to contains the newly selected variable when the user returns as it's refreshed or alternatively passed as a url parameter to the returning page.
I have a new page where I'd like the variable from my shared complex page to be returned. However there will be multiple instances of this variable on the page and they're actually different data to the previously stored single variable on the user data in the C# back end. i.e. I'd like to have several buttons on the page that lead to my shared complex page and when the user returns the data for each button will be displayed next to the button.
Is there a way in JavaScript or C# to display another page and have the result returned to the method that instantiated the display of the page? If my back end was implemented in scheme I'd use a continuation to achieve this result. Is there any equivalent in C#? I've been looking at async tasks in C# but none of the examples show a user interacting with another page as part of the asynchronous operation. Is this possible?
If not I'll have to pass the value back to the new page via URL parameters. I would like to avoid this because of the amount of contextual data I'd need to pass between the two pages. I'd thought of using a redirect from the shared complex page to update the new data on the back end before returning to the new page to solve half the problem but this site works on mobile so the network latencies rule out redirects. Also having the complex shared page as a pop up dialog within the new page won't really work as it's a) complex b) the new page can be used a pop up on an existing page and having a pop up from a pop up is unsupported on Bootstrap.
The sharing of data between web pages, without an established continuation medium, requires the use of a shared state somewhere, like session variables or cookies. As each page changes the state, it can go back to the server, update that session, and when the process is done, you'd read that session via ajax and complete your process.
What is page object in terms of asp.net?
Please give me some information:
How can we use it in asp.net?
and
Why we are using it?
I tried to search on the internet but couldn't find a proper answer that I could easily understand.
ASP.Net WebForms, like other web platforms, is still in the business of generating responses to http requests.
When a user visits a page on your site, the web server (IIS) receives the request. Because your site has a handler set up in a certain way (by default this is done for you automatically), IIS determines that this request will be processed by the ASP.Net runtime. The ASP.Net runtime then looks up what page you requested, and uses that information to create a new page object for this request.
It's worth noting at this point that you get a new page object even if the request is just a postback to the same page the user just visited. This page object only lasts for the life of this one request, and will be discarded when the request is complete, even though the user might still be interacting with the page on their browser. A new postback will generate a new page object. A lot of people have trouble wrapping their heads around this.
Once the page object is created, the ASP.Net runtime goes through a process called the Page Lifecycle. This involves steps like loading View State, loading the Session, binding to data sources, and raising user events. Between each of the stages, an event (such as Page Load) is raised that allows you to run any custom code you want to run at this particular point in the life cycle.
At the end of the life cycle, the html result for this page is transmitted to the browser, so it can be shown to the user. At this point the page object is destroyed, and the worker thread in IIS is free to handle another request.
I understand that Server.Transfer doesn't make a round trip back to the requesting client.
What I haven't been able to learn is if control is simply passed directly to the new request handler you're transferring to or if or if the entire request life-cycle is executed again.
I assume the entire life-cycle is executed again using the transfer URL but wanted to verify this was the case.
Here is what I found through experimentation.
When using Server.Transfer the entire request life cycle is not ran again.
If you write your own Module, hook it into the request life cycle, and call Server.Transfer from that module the rest of the request life cycle will be skipped and the page life cycle will begin immediately.
After completing the transfer page life cycle the request life cycle picks back up with its tear-down events. Note, the HtppContext in for the tear-down events will be the original one you transferred from. That is, the URL and QueryString values will be the same as the original request and not be the URL and QueryString values for the page you transferred to.
Server.Transfer does modify the HttpContext.Request object to contain the new URL and QueryString information during the page life cycle for the page you transferred to.
If you transfer to a resource that is not a page but is text based (e.g. something.xml) the content of that page will be returned exactly as is with its encoding set to text/html.
If you transfer to a resource that is not a page and is not text based (e.g. something.pdf) then an HttpException error will be thrown. This happens even if you have defined a custom Handler for this resource.
It's just passed along, with its state intact. The request lifecycle does not get run again, although the page lifecycle will run for the page you're transferring to.
http://msdn.microsoft.com/en-us/library/ms525800(v=vs.90).aspx
Server.Transfer acts as an efficient replacement for the Response.Redirect method. Response.Redirect specifies to the browser to request a different page. Because a redirect forces a new page request, the browser makes two requests to the Web server, so the Web server handles an extra request. IIS 5.0 introduced a new function, Server.Transfer, which transfers execution to a different ASP page on the server. This avoids the extra request, resulting in better overall system performance, as well as a better user experience.
This link is also helpful -
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm
I have a user complaining about frequent timeouts in my Intranet web page. While looking for a solution I found this post:
http://forums.asp.net/t/152925.aspx?PageIndex=1
Where a poster recommends intercepting the redirect to the login page, submit the data to the database, then either reauthorize the user (without their knowledge) or redirect to login page. My goal is to avoid the situation where a user enters data in a form, walks away, then comes back to submit it, only to be told they have to login again (which is fine, if the data remained and the user was sent right back to the original webform).
Does anyone know how I can accomplish this on specific pages in my app (not all of them)?
It's not necessarily trivial, but you can add an ajax component that makes occasional calls to a page to keep the session alive. This way you could lengthen the session for any particular page you need to without affecting the application as a whole.
EDIT
If you really want to let the session expire, but keep the form data, you can implement
protected void Application_PostAuthenticateRequest (object sender, EventArgs e)
event handler in your global.asax.cs file. This is called before the forms authentication redirect happens, and the form data is available to your application at this point, so you can persist it to whatever medium is necessary until your user is authenticated again. In addition, if you check the
((HttpApplication)sender).Request.Path
property it will tell you which page was requested.
Well, the easy way it to drastically lengthen the timeout specified in the web.config file.
I'm going to try using cookies to preserve the data. My plan is to update the user's cookie after each control is changed, then add logic to the page_load property of the page to populate the form data after the user is logged back in.