views:

432

answers:

6

Update: the clearest explanation I have found on the web as I have been struggling through this can be found here.

Maybe I just don't understand the model of runat server terribly well. It appears the following code is always executing the if block. If the code is running on the server side I guess I can understand that it has to be stateless.

I am a seasoned non-web programmer but it appears counter intuitive to me. Will I need to create some sort of session object or pass the current state along in the URL or what?

<script runat="server">

DateTime begin;
DateTime end;
int iSelectedStart = 0;
int iSelectedEnd = 0;
int iPutName = 0;

protected void Button1_Click(object sender, EventArgs e)
{
    if (iPutName == 0)
    {
        iPutName = 1;
        Label1.Text = TextBox1.Text + " you will be slecting your start and end dates.";
A: 

Because ASP.NET is stateless what you're assuming is correct. The postback will cause the page to lose the variable for iPutName. Storing in session is one option, or storing in viewstate could be another option.

The main thing to understand here is how the ASP.NET page lifecycle works and what happens each time you post back to the server.

lomaxx
+2  A: 

The important thing to remember here is that the web is stateless. Each request from a person's browser is completely separate from all previous requests. What's happening with your code is that the class is being instantiated from scratch each time the client requests a page. That includes clicking Button1.

If you want values to persist between requests, you have to store it in a location where it can be retrieved later. The Session object provides this for you.

Basically, you'll need to store the iPutName variable in the session somehow. Probably the nicest way is to encapsulate it in a property:

protected int iPutName
{
    get { 
        if (Session["iPutName"] == null)
            Session["iPutName"] == 0;
        return Session["iPutName"];
    }
    set { Session["iPutName"] = value; }
}

Edit: The ViewState object will work as well (as long as ViewState is turned on on the page). This encodes the value in a hidden field in the HTML and decodes it when it comes back.

Edit (again): Apologies for repeated edits, but I should clear this up. What Jonathan and Emil have said is correct. You should probably be using ViewState for this rather than Session unless you want this value to remain accessible between pages. Note that this does require that ViewState is turned on and it will result in a larger payload being sent to the client.

Damovisa
A good point from Jonathan's answer - the Session object will be persisted across all pages in your application. ViewState will only be persistent within the same page.
Damovisa
+2  A: 

It looks like part of your code got cut off, but here's the basic thing with web programming -- it's stateless. Unless, that is, you do something (use ViewState, Session, etc.) to add some state into the mix.

In your case, it looks like you want to maintain some state through refreshes of the page. Put the values you want to preserve in ViewState to keep them across postbacks to the same page. If you want to hold values across pages on your site, use Session. If you want to maintain values across visits to the site, put them in a database and tie them to a login or cookie.

Jonathan
Good point about Session being across multiple pages vs. ViewState being within the one page.
Damovisa
A: 

For the lifecycle, check out the following URL : http://www.eggheadcafe.com/articles/20051227.asp

You can store your iPutName in the session by doing this :

Session["iPutName"] = iPutName;

Fetching the session variable is also easy, but you should be sure to do a NULL check, like this:

if (Session["iPutName"] != null) iPutName = Session["iPutName"];

Haven't tested any of this, but if you encounter typos... sorry ;)

Wim Haanstra
That link is a little scary...
ojblass
+2  A: 

I really recommend to look at the quick start tutorial.

http://quickstarts.asp.net/QuickStartv20/aspnet/Default.aspx

There are a lot of concepts in dot net to simulate state on the UI. In your case I think what you really want to do is using viewstate. Sessions should be used with care and I think the concept you are looking for i localized to the page not to the entier user session.

You should also look at the concept codebehind/codefront as well.

Emil C
A: 

The Url you posted in your update is definitely not "All You Want to Know" about ViewState.... not even close. I only scanned his article but he doesn't appear to address Page Life Cycle at all. If your going the View State route then read these 2 links:

Understanding ASP.NET View State by Scott Mitchell

Truly Understanding ViewState By Dave Reed

If you're new to ViewState then dump all that guff (1 half the article) about parsing ViewState mentioned in your linked article. It's simply not required for anything but highly specialized scenarios. It is definitely not a normal thing to be doing re:ViewState.

rism