We have inherited an ASP.Net site with two search forms on it, one with validation, one without. Each form has its own button -and its own events.
When the page is left open (idle) for about 20 minutes and then submitted using the form without any validation, the page posts back but the events aren't fired. I know that the page is posting back because I've checked that Page.IsPostBack == true.
What's curious about this is that the Page Validators are fired (even though the button clicked has CausesValidation=false) and the page appears to just be refreshed. To me, the fact that it happens after 20 minutes makes me think it's tied into the session timeout and although I could just extend the session timeout (or create a keep-alive/ping system), I would have thought there's a more practical solution to this issue.
Has anyone else come across this issue before and if so, how did you resolve it?
Yep I was right, we implemented a quick fix to move viewstate into session which is usually fine but because the session was timing out, ViewState was lost and then the events didn't know where to fire.
Related
I have two controls of interest on a page: a DropDownList and a Button. If the user presses the button, he gets a popup form which, when completed, causes the base page to completely reload, losing the value in the DropDownList. To clarify, it's a refresh, not a postback. I cannot change it to make it a postback. What is the most straightforward way of persisting the selected value in the DropDownList across this page refresh? I cannot avoid the page refresh, because the data entered in the popup is reflected elsewhere on the base page.
Update
I've cobbled together a tenative solution that I'm not terribly happy with: when the user clicks the button, I use javascript to get the current value of the dropdown and pass that with the querystring to the popup being loaded. When the user clicks "Save" on the popup, which causes the data to be saved then the base page to be reloaded, I first store the querystring value into a Session variable. The base page, on loading, looks at said Session variable. If a value is present, it sets the value of the dropdown accordingly and deletes the Session variable.
Although somewhat kludgy, it's the best I can come up with. I know that my Gracious Benefactors dislike using Session variables, but given the page reload, I cannot come up with an alternative. Also, since the Session variable is short-lived, being created shortly before a page is closed then being deleted shortly after the succeeding page is opened, I'm hoping this will be acceptable.
Contrasting opinions, refutating my solution or reasoning, are enthusiastically welcome.
Conclusion
Ultimately, after I described the solution to my Gracious Benefactors, we agreed upon an alternate approach: if a selection is made in the DropDownList, it must be saved before opening the popup. This avoids the whole ViewState problem altogether.
For updated question:
The solution you are trying sounds like it should work. It's not the sort of thing you want to use SessionState for but there are requirements here that make the situation out of the ordinary.
Depending on how you are getting the base page to reload you may be able to add a query string to that which would save you from putting hte value in the SessionState. But I imagine you have probably considered that.
But basically, as Postback values and viewstate are out of the question, SessionState and query strings are you only real option. Oh, unless you are allowed to use HTML5 local storage? (probably not)
From before question update:
If the aspnetForm is being posted back the the value should be persisted automatically by means of the postback values. So the first thing to know is whther your form is going through a postback or if you are refreshing the page in some other way.
If you can't postback the main form then as rockinthesixstring said an Ajax post might be what you need.
Also, if you are doing anything fancy with binding the datasource to the DropDownList or trying to persist the selectedValue yourself then check and re-think that.
When I run the web application, I notice that Page_PreRender is fired twice. This only happens the first time in a new session. It does not happen if I refresh the page, or on postbacks.
I use .NET framework 3.5 and the built in ajax functionality.
The problem is not
related to img tag with empty src
attribute (which I have seen other posts with similar problem
has mentioned). I know this because I see this in
both FireFox and IE. The posts I saw
about this stated that this was not a
problem in IE. I have also searched
and found no img tags with empty src
in the generated page source, so it
should not be this.
I have also made a simple test
page where I have included some of
the functionality, and this does not
happen.
Have anyone any suggestions on what happens?
Note:
It is the entire page cycle that is firing twice, not just render.
I've experienced it; it's probably not what you are experiencing, but I'll enter it here anyway; I've noticed it when the application does a Response.Redirect at the PreRender level, which a redirect does not stop current execution, but makes it appear the event happens twice...
Again, probably not related, but including it just in case.
I copied some code that states:
Page.LoadComplete += new EventHandler(Page_PreRender)
I did not realize that this code fire for second time my Page_PreRender event.
When I comment it, never fire twice.
I have a small 4-page application for my customers to work through. They fill out information. If they let it sit too long, and the Session timeout out, I want to pop up a javascript alert that their session has expired, and that they need to start over. At that point, then redirected to the beginning page of the application.
I'm getting some strange behavior. I'm stepping through code, forcing my Sessioni.IsNewSession to be true. At this point, I write out a call to Javascript to a Literal Control placed at the bottom of the . The javascript is called, and the redirection occurs.
However, what is happening is.. I am pressing a button which is more or less a "Next Page" button and triggering this code. The next page is being displayed, and then the Alert and redirection occurs. The result I was expecting was to stay on the same page I received the "Timeout", with the alert to pop-up over it, then redirection.
I'm checking for Session.IsNewSession in a BaseClass for these pages, overriding the OnInit event.
Any ideas why I am getting this behavior?
Thanks!
There multiple ways u can do this. Have hava Script timer as per u session timeout (Default is 20 min). After 19 min just rasise a alert on client and submit the page to the same page to refresh. This may not good option given user would have entered lot of stuff already
Or other way is don't session time out this page. U can do this on back ground just refresh the page after 19 min (U can do this by placing one div and iframe or image request on the server.). This might be good experiance for the user the reason is he don't have to enter the content again. Talking to u client giving this kind of option is worth sometimes.
Rather than using the Session object or storing to the database, I am storing temporary variables that I need persisted to custom ViewState variables. For example, ViewState("MyField1") = 1
When the user hits the browser Rrefresh button, Page.IsPostback is back to False and the ViewState is gone.
My question is. If the user can blow away the Viewstate by refreshing, why would anyone use it?
I know that a Refresh reposts the last submitted page, by why is Page.IsPostback reset to False and the ViewState blown away?
Flame me if you want for creating a potential dup question, but I've read other postings here, and it ain't sinking in...
Update to original post:
I now think that it has to do with postbacks that are performed as a result of clicking on Buttons that are within an UpdatePanel. Can someone help shed some light on this?
When a client refreshes their browser, it re-submits the last full page request issued by the client (which may be a GET or a POST). It does not ever resubmit AJAX requests such as those produced by update panel event triggers ("partial page postbacks").
The fact that Page.IsPostback is false when you refresh the page means that your original request is a GET, so here's what's probably happening:
1) During the initial request, the client sends no form data to the server - hence no hidden field containing view state data (Understanding ASP.NET View State is pretty detailed, but a great read if you want to really understand what's going on). While processing this request, ASP.NET may send some view state back to the client, but the original request is just a URL.
2) When the user clicks a button within an UpdatePanel, they trigger a partial postback during which MyField is set to 1. The UpdatePanel changes the client's view state to reflect the new value.
At this point, if the user submits a POST request by normal means, such as clicking a button, the view state will contain the updated information.
If the user clicks 'Refresh' though, they re-submit the original request from step 1, with no form data and therefore no view state.
Where do you set your ViewState? And where do you re-read your ViewState value? Maybe oyu check its content before asp.net calls the LoadViewState() method.
User hitting refresh and using updatepanel will not work together very well. I quess this is why people say that WebForms provides a leaky abstraction on web programming and some are moving to mvc.
If you're not interested in migrating, I'd give you the advice that do not use updatepanel for too long or big operations, where you can assume that user might refresh the page. Use it for small things like dropdown2 items changing when selection on dropdown1 changes.
Wrapping lots of functionality in one updatepanel will cause trouble, if you just depend on viewstate.
Your question is, "Why would anybody use it."
Viewstate comes in handy for data you know is generated by a post back. Hitting refresh is not a post back, but a fresh request.
So lets say you are browsing a datagrid and you need to know certain bits of data about what they have clicked, on the click event you could store that data in the viewstate and process it during other times in the page life cycle, or subsequent post backs.
ViewState's advantage is that it is just embedded into the HTML, so it is all client side. Where as SessionState is server side, and if you store a great amount of data in the session you can cause your web or db server to work harder to handle that data.
Hope this helps.
Don't know why it works but I had a similair problem and solved it by putting this line in the form_load:
me.myProperty = me.myProperty
where
Public Property myProperty() as String
Get
If Not IsNothing(ViewState("data")) Then
Return CType(ViewState("data"), String)
Else
Return String.Empty
End If
End Get
Set(value As String)
ViewState("data") = value
End Set
I'm hoping someone has seen this before because I can't for the life of me find the problem.
I'm trying to do the old "fix the back button" thing in an application and I think i have a pretty decent approach, the problem is that it relies on the application not calling page_load when you hit back and instead loading the cached version of the page.
On about 60% of my pages that's exactly what happens. It loads the cached version and all is well. On the other 40% when i hit the back button page_load calls, forcing a refresh. For reference the call to page_load is NOT in a postback.
Even stranger is that this only occurs in IE (6 & 7). In firefox page_load never gets called.
I am using ASP.NET Ajax framework on both types of pages. Anyone seen anything like this before?
--Update--
After investigating a bit more I'm finding out that when i use the search to navigate from one page to another the application behaves differently for different pages. On the broken pages the page_load gets called twice, the search gets called twice and in fiddler that turns into 2 different redirect postbacks the second of which has no-cache set.
On the working page page_load and search only happen once and it immediately redirects.
That second Response.Redirect is causing the issue. Still not sure why that's happening though.
Check what the server is returning for the cache-control http header, then try setting Response.Cache.SetCacheability()/ use the output cache page directive on the pages and see if the server is saying that the pages should be cached.
if you are using ASP.NET AJAX why not using the History server control object?
replacing History, the back button will go to the link you want.
try this