views:

515

answers:

9

Here's the situation: I have a label's text set, immediately followed by a response.redirect() call as follows (this is just an example, but I believe it describes my situation accurately):

aspx:

<asp:Label runat="server" Text="default text" />

Code-behind (code called on an onclick event):

Label.Text = "foo";
Response.Redirect("Default.aspx");

When the page renders, the label says "default text". What do I need to do differently? My understanding was that such changes would be done automatically behind the scenes, but apparently, not in this case. Thanks.

For a little extra background, the code-behind snippet is called inside a method that's invoked upon an onclick event. There is more to it, but I only included that which is of interest to this issue.

A: 

Where are you doing this in the code behind? Page Load? Render? Init?

Chuck
I'll clarify, thanks.
MrBoJangles
A: 

Why exactly are you doing a redirect in this scenario? It seems unnecessary.

chrisofspades
There's more to it. Think in academic terms, not practical terms.
MrBoJangles
The other answers pretty much sum up why I felt the redirect was unnecessary, but I wanted to see if there were other reasons you took that approach. Academically, it didn't make sense to me, but sometimes we're forced to do things in an unorthodox manner.
chrisofspades
True that. I guess the reason I was doing it this way was because this is someone else's code I'm modifying. I did find a way that worked that didn't use a redirect.response(). Thanks.
MrBoJangles
+1  A: 

ASP and ASP.Net are inherently stateless unless state is explicitly specified. Normally between PostBacks information like the value of a label is contained in the viewstate, but if you change pages that viewstate is lost because it is was being stored in a hidden field on the page.

If you want to maintain the value of the label between calls you need to use one of the state mechanisms (e.g. Session, Preferences) or communication systems (Request (GET, POST)).

Additionally you may be looking for Server.Transfer which will change who is processing the page behind the scenes. Response.Redirect is designed to ditch your current context in most cases.

Orion Adrian
So a redirect will not hold over view state but a postback will?
MrBoJangles
+3  A: 

A Response.Redirect call will ask the user's browser to load the page specified in the URL you give it. Because this is a new request for your page the page utilises the text which is contained in your markup (as I assume that the label text is being set inside a button handler or similar).

If you remove the Response.Redirect call your page should work as advertised.

Aydsman
As the redirect is necessary, I'll have to find a different way to populate the label. Good to know, thanks.
MrBoJangles
+1  A: 

After a redirect you will loose any state information associated to your controls. If you simply want the page to refresh, remove the redirect. After the code has finished executing, the page will refresh and any state will be kept.

Behind the scenes, this works because ASP.NET writes the state information to a hidden input field on the page. When you click a button, the form is posted and ASP.NET deciphers the viewstate. Your code runs, modifying the state, and after that the state is again written to the hidden field and the cycle continues, until you change the page without a POST. This can happen when clicking an hyperlink to another page, or via Response.Redirect(), which instructs the browser to follow the specified url.

David Thibault
A: 

So, if I may answer my own question (according to the FAQ, that's encouraged), the short answer is, you don't persist view state through redirects. View state is for postbacks, not redirects.

Bonus: Everything you ever wanted to know about View State in ASP.NET, with pictures!

MrBoJangles
yep, the viewstate is actually contained in a hidden input control, b64 encoded. So, if you do a response.redirect, it's history.
stephenbayer
+1  A: 

To persist state, use Server.Transfer instead of Response.Redirect.

Nikki9696
I'll try it, thanks!
MrBoJangles
A: 

For what it's worth (and hopefully it's worth something), Chapter 6 of Pro ASP.NET 3.5 in C# 2008, Second Edition is a terrific resource on the subject. The whole book has been great so far.

MrBoJangles
A: 

could dump the value to the Context.Items

hunter