If I set on my page : EnableViewState="true" ViewStateMode="Disabled"
- Then - the Viewstate is disable for the page ( unless override...)
Then, trying to read from (assuming the control has been populated in the last dump to the screen and a value is selected):
MyDDL.SelectedValue
will yield ""
That's because of disabled viewstate :
But my question is at a higher level :
If it's all about a form value (which I still can get from
Request.Form[MyDDL.UniqueID]
) - and we're talking about an input which doesn't need anything to save its value.Why does the
DropDownList
property named (SelectedValue
) Is relied on ViewState ?
p.s. the TextBox onchangeevent does rely on viewstate although the control is an input (which doesnt need viewstate) - it saves the value of the text and then it compare it when postback.But it only relies on viewstate when you set onchange event ( and autopostback)
If you want the DropDownList to work without ViewState, you can bind the control in page_load only once as given below:
In the case ( ViewState is disabled), Asp.net FrameWork retrieve the items from the back end with every PostBack.
In the case (ViewState is enabled), Asp.net FrameWork retrieve the items from the ViewState without hitting the back end with every PostBack
Normally, the Asp.net FrameWork fire the data binding events in PreRender event: Read ASP.NET Page Life Cycle Overview
You can confirm that behavior by enabling Trace.
SelectedValue doesn't rely directly on ViewState from source code of ListControl , BUT depend on items as described above.
The
SelectedValue
relies onViewState
because on PostBack it rebuilds itsListItems
from theViewState
and then sets the selected value on theDropDownList
from theRequest
Object.It is not taking the
Request
value as theSelectedValue
directly. This in turn is because, ASP.Net can check if the postedDropDownList
has not been tampered with at the client. It does so by first de-serializing the original items from theViewState
. It then finds theRequest
Value in the items and sets itsSelected
property astrue
. Only now, theSelectedValue
property is available. (orSelectedIndex
for that matter). It should be able to fire aSelectedIndexChanged
event now.This is also the reason that you do not need to bind the
DropDownList
again inPageLoad
. The list items are automagically retreived from theViewState
.If the
ViewState
is disabled, then there will be no original list items in theViewState
and will be empty. Hence it will not be able to mark any item as selected. Hence theSelectedValue
will be 0 or theSelectedItem
will be null. I think theSelectedIndexChanged
event will also not fire. For things to work in this case databinding needs to be done, preferably oninit
.There are workarounds to that however.
Complete Reference: http://msdn.microsoft.com/en-us/library/ms972976.aspx
Edit: (after Op's comments)
Following the page life cycle to see where
SelectedValue
relies onViewState
:Stage 1 Init: The control heirarchy is built. If the DropDownList is bound here or the ListItems have been added declaratively, the List gets populated here.
Stage 2 Load ViewState: On PostBack, the ViewState is validated here and loaded into the DropDownList. There is no
SelectedValue
here.Stage 3 Load PostBack Data: Here the
Request
Value (from the form request) is taken and then applied to the control. In this case ofDropDownList
it now sets theSelectedValue
from the receivedRequest
Object Value, internal implementation is something like this:What is important here is that if ViewState is not there and DropDownList is not data-bound, then the ListItem collection will be empty and hence
SelectedValue
property is 0. This has nothing to do with internal implementation of a property.If the ViewState is not there (disabled) and DropDownList is data-bound, then the ListItem collection will exist and corresponding item will be marked as selected and hence
SelectedValue
property will return the correct value.If the item collection is new (thru a re-binding with different data set or ViewState is invalidated), then the
Request
Form value would not be found in the item collection and againSelectedValue
will be invalid.Stage 4 Page Load: by this time the ViewState (or data-binding) and PostBack Data has already been loaded.
Stage 5 Raise PostBack Event: At this stage the
OnSelectedIndexChanged
event of DropDownList is fired if the index was changed in Stage 3.Hence, the
SelectedValue
relies on ViewState at Stage 3. Of course, if the control is appropriately data-bound then it will not rely on ViewState as a corollary.SelectedValue
relies on ViewState to make sure the items collection has been populated prior to setting it. Data-binding / Re-binding is just another way to make sure the items collection is populated.Hope that clarifies.
SUMMARY: If you want the control to work without ViewState, you need to populate/bind the Items collection on every postback. I recommend doing it in the Page_Init event (i.e. OnInit method).
First off, I always recommend this this awesome article: TRULY Understanding ViewState.
The SelectedValue doesn't require ViewState. Looking at the code for ListControl, which DropDownList inherits from, we see the code:
The important thing to take away from this code is that the Items list must be populated to get the SelectedValue.
If you utilize ViewState, the Items collection is persisted to / loaded from ViewState, which allows the SelectedValue property to work without rebinding the control.