S
Simon
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
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