S
seven
I have a base page with an HTMLForm object (added to the base page control
heiarchy during Init).
In the design of pages derived from this base page, I can choose to create
controls and add them to the HTMLForm object I'm inheriting, to create a
postback form. And on one particular page I'm doing just that; defining
controls on the derived page (during Init) and adding these controls to the
inherited HTMLForm object's control collection. These controls include a
dropdownlist (that autopostbacks) and a submit button. The dropdownlist is
physically above the button in the HTMLForm's control heiarchy.
In the codebehind of the derived page, I have a event handlers for both the
dropdownlist's SelectedIndexChanged event (to handle the autopostback of the
dropdown) as well as the button's Click event.
During the Init process of the derived page, I instantiate the dropdown and
the button (as well as the other input controls for the form) and add them
to the HTMLForm's control heiarchy. I do this during Init based on my
belief that that LoadViewState, which occurs after init, expects to find an
identical form control heiarchy between postbacks. So the form has to be
established and receptive by the end of the Init phase.
Now here's the problem I'm experiencing: if I post back to this page, the
SelectedIndexChanged event is firing on every postback, irrespective of
whether or not the button or the dropdown is used to invoke the postback.
I have a guess at the reason for this - during Init, when the dropdown is
instantiated, it's selectedIndex is 0. When LoadViewState does it's thing,
it's changing the selectedIndex to (whatever the user had selected) and this
triggers a SelectedIndexChanged event. (?)
If that's correct, then I thought I'd resolve it one of two ways - either
check the viewstate of the dropdown against it's selectedindex/value and use
that as a way to determine if the combo "really" had it's index changed
(i.e. by the user) or, maybe obtain the viewstate data and assign the
selected index prior to loadViewState happening.
Both of those methods have been shot down due to the fact that ViewState is
nothing at all points of the lifecycle I can think of to check it. Init,
Load, PreRender, LoadViewState - It's always nothing.
But the application *is* restoring viewstate. If I override LoadViewState,
the savedState object is always nothing. So I don't understand how to read
the viewstate, aside the __VIEWSTATE in request.form, but that's not very
helpful to me. I expected to be able to access Me.ViewState(somekey) (or at
least maybe MyBase.ViewState(somekey)) but it's always empty. I don't
understand how the page is actually restoring it's viewstate, if it's always
empty to me? Confusing.
heiarchy during Init).
In the design of pages derived from this base page, I can choose to create
controls and add them to the HTMLForm object I'm inheriting, to create a
postback form. And on one particular page I'm doing just that; defining
controls on the derived page (during Init) and adding these controls to the
inherited HTMLForm object's control collection. These controls include a
dropdownlist (that autopostbacks) and a submit button. The dropdownlist is
physically above the button in the HTMLForm's control heiarchy.
In the codebehind of the derived page, I have a event handlers for both the
dropdownlist's SelectedIndexChanged event (to handle the autopostback of the
dropdown) as well as the button's Click event.
During the Init process of the derived page, I instantiate the dropdown and
the button (as well as the other input controls for the form) and add them
to the HTMLForm's control heiarchy. I do this during Init based on my
belief that that LoadViewState, which occurs after init, expects to find an
identical form control heiarchy between postbacks. So the form has to be
established and receptive by the end of the Init phase.
Now here's the problem I'm experiencing: if I post back to this page, the
SelectedIndexChanged event is firing on every postback, irrespective of
whether or not the button or the dropdown is used to invoke the postback.
I have a guess at the reason for this - during Init, when the dropdown is
instantiated, it's selectedIndex is 0. When LoadViewState does it's thing,
it's changing the selectedIndex to (whatever the user had selected) and this
triggers a SelectedIndexChanged event. (?)
If that's correct, then I thought I'd resolve it one of two ways - either
check the viewstate of the dropdown against it's selectedindex/value and use
that as a way to determine if the combo "really" had it's index changed
(i.e. by the user) or, maybe obtain the viewstate data and assign the
selected index prior to loadViewState happening.
Both of those methods have been shot down due to the fact that ViewState is
nothing at all points of the lifecycle I can think of to check it. Init,
Load, PreRender, LoadViewState - It's always nothing.
But the application *is* restoring viewstate. If I override LoadViewState,
the savedState object is always nothing. So I don't understand how to read
the viewstate, aside the __VIEWSTATE in request.form, but that's not very
helpful to me. I expected to be able to access Me.ViewState(somekey) (or at
least maybe MyBase.ViewState(somekey)) but it's always empty. I don't
understand how the page is actually restoring it's viewstate, if it's always
empty to me? Confusing.