Persisting DataSource on Postback using ViewState

[Chris Carter]

Hi All,
Ok, I've got a server control that implements custom databinding and
generates a list of RadioButtons. (Yes, you'd think why not use the off the
shelf RadioButtonList; because the RadioButtonList contains a collection of
ListItems and not RadioButtons. We needed to disable a particular item in
the RadioButtonList but apparently there is no way of disabling a ListItem -
if there is, someone tell me!) Anyway, here's the problem:

The control works like a champ except for one thing. The databinding
implementation is somehow different than that of a standard out of the box
control you get with asp.net. With say a DropDownList, you can do the
following:
if (!Page.IsPostBack)
MyDropDownList.DataBind();
and with this, it'll only hit the DataBind() once, when the page first
loads. Everytime after that it uses viewstate.

I understand why that works and have no questions about that. My question
revolves around "how" it saves it's state to viewstate. Using the ViewState
decoder found here http://staff.develop.com/onion/resources.htm I can bind a
normal DropDownList to a DataSource and use that tool to actually see the
values it's storing in viewstate. The only way I came up with saving my
custom datasource to viewstate was something like this:
//During the initial DataBind() call
ViewState["MyDataSource"] = MyDataTableDataSource;

Then on postbacks I use ViewState["MyDataSource"] as the DataSource.
Although that works it's bothering me that it's working differently than the
standard controls. Decoding the viewstate of my custom control reveals that
the way i'm saving my datasource to viewstate is different, it shows my
variable name having a Binary value and the Binary value is HUGE for a
datatable consisting of 2 rows and 2 short columns. I tried using the
examples here
http://msdn.microsoft.com/library/d...html/cpcontemplateddataboundcontrolsample.asp
but just couldn't figure out how they were saving the DataSource to
viewstate. They save only enough info to repopulate the controls on
postback which is what I want, i don't want to save my entire datatable or
dataset to viewstate.

Anyone have any ideas on this?

TIA,
Chris

 

[John Saunders]

Hi All,
Ok, I've got a server control that implements custom databinding and
generates a list of RadioButtons. (Yes, you'd think why not use the off the
shelf RadioButtonList; because the RadioButtonList contains a collection of
ListItems and not RadioButtons. We needed to disable a particular item in
the RadioButtonList but apparently there is no way of disabling a ListItem -
if there is, someone tell me!) Anyway, here's the problem:

The control works like a champ except for one thing. The databinding
implementation is somehow different than that of a standard out of the box
control you get with asp.net. With say a DropDownList, you can do the
following:
if (!Page.IsPostBack)
MyDropDownList.DataBind();
and with this, it'll only hit the DataBind() once, when the page first
loads. Everytime after that it uses viewstate.

I understand why that works and have no questions about that. My question
revolves around "how" it saves it's state to viewstate. Using the ViewState
decoder found here http://staff.develop.com/onion/resources.htm I can bind a
normal DropDownList to a DataSource and use that tool to actually see the
values it's storing in viewstate. The only way I came up with saving my
custom datasource to viewstate was something like this:
//During the initial DataBind() call
ViewState["MyDataSource"] = MyDataTableDataSource;

You don't save the data source to ViewState. On the initial request, you use
the data source to set the properties of your child controls. Then, when you
recreate the child controls on subsequent postbacks, the child controls will
load their own properties from ViewState. You may also need to use ViewState
to save some properties of the control as a whole which are not properties
of the child controls. For instance, you may need to keep track of the
number of child controls and which one is disabled. You can use these on
PostBack to recreate the appropriate number of child controls and to
disable the proper control.

 

[Chris Carter]

Thanks John, I was under the impression i would only have to recreate the
radiobutton with the original ID(before viewstate was evaluated) and the
rest of it's attributes would be persisted automatically thru viewstate.
Anyway, i needed to save the GroupName, Text, value, and ID to viewstate on
my own using a combination of arraylist, pair, and triplet objects then
recreate those on postback and all worked out fine. Thanks again for the
response.

Hi All,
Ok, I've got a server control that implements custom databinding and
generates a list of RadioButtons. (Yes, you'd think why not use the off the
shelf RadioButtonList; because the RadioButtonList contains a collection of
ListItems and not RadioButtons. We needed to disable a particular item in
the RadioButtonList but apparently there is no way of disabling a ListItem -
if there is, someone tell me!) Anyway, here's the problem:

The control works like a champ except for one thing. The databinding
implementation is somehow different than that of a standard out of the box
control you get with asp.net. With say a DropDownList, you can do the
following:
if (!Page.IsPostBack)
MyDropDownList.DataBind();
and with this, it'll only hit the DataBind() once, when the page first
loads. Everytime after that it uses viewstate.

I understand why that works and have no questions about that. My question
revolves around "how" it saves it's state to viewstate. Using the ViewState
decoder found here http://staff.develop.com/onion/resources.htm I can

bind

a
normal DropDownList to a DataSource and use that tool to actually see the
values it's storing in viewstate. The only way I came up with saving my
custom datasource to viewstate was something like this:
//During the initial DataBind() call
ViewState["MyDataSource"] = MyDataTableDataSource;

You don't save the data source to ViewState. On the initial request, you use
the data source to set the properties of your child controls. Then, when you
recreate the child controls on subsequent postbacks, the child controls will
load their own properties from ViewState. You may also need to use ViewState
to save some properties of the control as a whole which are not properties
of the child controls. For instance, you may need to keep track of the
number of child controls and which one is disabled. You can use these on
PostBack to recreate the appropriate number of child controls and to
disable the proper control.