How do I know when to use the Viewstate and when to use the posted data? :-)

Discussion in 'ASP .Net Web Controls' started by Simon, Nov 9, 2004.

  1. Simon

    Simon Guest

    Hi everyone,

    I have a quick question that I hope someone can help me with:

    I've made a user control that contains a text box and some validation
    functionality. This control has a few extra properties declared on it over
    and above that provided by the textbox.

    As I understand it, part of the process to make this work is, in the
    property accessor's for the properties that you wish to persist you add
    values to the ViewState and you remove values to the viewstate. I don't
    quite understand why yet but I think its something to do with maintaining
    state over postbacks.

    OK so far.

    When my control is loaded, it goes to the database and gets the information
    it needs to display. I'm not sure if I'm doing the right thing here or not,
    but I'll explicitly state my question in a couple of second.

    Once it gets the data it needs, it uses the set property accessors to
    initialise the control and have the values dropped into viewstate.

    When the page load in front of the user it seems to me that the page will
    have the values of internal controls actually in the controls themselves (as
    you'd expect), but also in the viewstate. Fair enough.

    My actual question is related to the following:

    When the user hits a submit button on the page amongst the other things that
    occur, the following happens:

    1. The values of the controls are posted back to me. If the user has changed
    any values in the textboxes or so on, thats where the changed will be (I
    think).

    2. Somehow, the viewstate is made available. I'm guessing that it's posted
    back as well, which seems a bit of duplicated effort but never mind but I
    guess the viewstate and the post variables may contain different info on
    occasions that the user has changed a value on the page. I dont have time to
    worry about that just now unfortunately.

    Question:

    Given that I have the viewstate and then also the actual values posted
    straight from the controls themselves the question is, do I just ignore the
    viewstate because it doesnt contain the most recent values or do I have to
    pay attention to it somehow. If the former is the case, then I don't see the
    point in the viewstate. If the later is the case, then I still don't see the
    point of the viewstate because as I understand it, all its going to contain
    is the values that were sent to the page on the way out. The value in the
    viewstate won't have changed when they come back in on a postback. The
    values of the controls may have been changed by the user, but then thats
    seperate from the viewstate (I think).

    If anyone can help me understand this without using the phrase "Viewstate is
    used to persist form values over postbacks" or something to that effect,
    then I would be very greatful.

    With many thanks in advance

    Simon
    Simon, Nov 9, 2004
    #1
    1. Advertising

  2. Simon

    Henri Guest

    Hi Simon,

    As far as I know, Viewstate is used to persist form values over postbacks
    only when you want to know if value has changed.

    For instance, try this :
    <input runat="server" type="text" name="myHtmlInputText" />
    You don't specify that you want to know if value has changed between posts,
    so viewstate isn't used (try it with trace="true") but the value is still
    persisted.

    Now if you write :
    <input runat="server" type="text" name="myHtmlInputText"
    onServerChange="myHtmlInputText_ServerChange" />
    You specify that you want to call myHtmlInputText_ServerChange when value
    has changed, so ViewState is used here: old value is saved in viewstate and
    then compared to the new one from Input to detect a change.

    Hope it helps
    Sorry for my bad English
    Henri

    "Simon" <sh856531@microsofts_free_email_service.com> a écrit dans le message
    de news:...
    > Hi everyone,
    >
    > I have a quick question that I hope someone can help me with:
    >
    > I've made a user control that contains a text box and some validation
    > functionality. This control has a few extra properties declared on it over
    > and above that provided by the textbox.
    >
    > As I understand it, part of the process to make this work is, in the
    > property accessor's for the properties that you wish to persist you add
    > values to the ViewState and you remove values to the viewstate. I don't
    > quite understand why yet but I think its something to do with maintaining
    > state over postbacks.
    >
    > OK so far.
    >
    > When my control is loaded, it goes to the database and gets the

    information
    > it needs to display. I'm not sure if I'm doing the right thing here or

    not,
    > but I'll explicitly state my question in a couple of second.
    >
    > Once it gets the data it needs, it uses the set property accessors to
    > initialise the control and have the values dropped into viewstate.
    >
    > When the page load in front of the user it seems to me that the page will
    > have the values of internal controls actually in the controls themselves

    (as
    > you'd expect), but also in the viewstate. Fair enough.
    >
    > My actual question is related to the following:
    >
    > When the user hits a submit button on the page amongst the other things

    that
    > occur, the following happens:
    >
    > 1. The values of the controls are posted back to me. If the user has

    changed
    > any values in the textboxes or so on, thats where the changed will be (I
    > think).
    >
    > 2. Somehow, the viewstate is made available. I'm guessing that it's posted
    > back as well, which seems a bit of duplicated effort but never mind but I
    > guess the viewstate and the post variables may contain different info on
    > occasions that the user has changed a value on the page. I dont have time

    to
    > worry about that just now unfortunately.
    >
    > Question:
    >
    > Given that I have the viewstate and then also the actual values posted
    > straight from the controls themselves the question is, do I just ignore

    the
    > viewstate because it doesnt contain the most recent values or do I have to
    > pay attention to it somehow. If the former is the case, then I don't see

    the
    > point in the viewstate. If the later is the case, then I still don't see

    the
    > point of the viewstate because as I understand it, all its going to

    contain
    > is the values that were sent to the page on the way out. The value in the
    > viewstate won't have changed when they come back in on a postback. The
    > values of the controls may have been changed by the user, but then thats
    > seperate from the viewstate (I think).
    >
    > If anyone can help me understand this without using the phrase "Viewstate

    is
    > used to persist form values over postbacks" or something to that effect,
    > then I would be very greatful.
    >
    > With many thanks in advance
    >
    > Simon
    >
    >
    >
    Henri, Nov 9, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon
    Replies:
    1
    Views:
    431
    Henri
    Nov 9, 2004
  2. rgouge
    Replies:
    0
    Views:
    336
    rgouge
    Jul 29, 2005
  3. =?Utf-8?B?SmF6eg==?=
    Replies:
    5
    Views:
    455
    Bill Gregg
    Apr 28, 2006
  4. Tumurbaatar S.

    ViewState and posted back data

    Tumurbaatar S., Nov 27, 2005, in forum: ASP .Net Building Controls
    Replies:
    1
    Views:
    145
    Sundararajan
    Nov 29, 2005
  5. Andries

    I know, I know, I don't know

    Andries, Apr 23, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    215
    Gregory Toomey
    Apr 23, 2004
Loading...

Share This Page