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 [url]http://staff.develop.com/onion/resources.htm[/url] 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
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcontemplateddataboundcontrolsample.asp[/url]
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]

"Chris Carter" <chris@panteravb.com> wrote in message
news:uy5jUcQhDHA.3700@TK2MSFTNGP11.phx.gbl...

> 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 [url]http://staff.develop.com/onion/resources.htm[/url] 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.
--
John Saunders
Internet Engineer
[email]john.saunders@surfcontrol.com[/email]

[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.

"John Saunders" <john.saunders@surfcontrol.com> wrote in message
news:u$INC9RhDHA.2960@TK2MSFTNGP11.phx.gbl...

> "Chris Carter" <chris@panteravb.com> wrote in message
> news:uy5jUcQhDHA.3700@TK2MSFTNGP11.phx.gbl...

> > 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 [url]http://staff.develop.com/onion/resources.htm[/url] 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.
> --
> John Saunders
> Internet Engineer
> [email]john.saunders@surfcontrol.com[/email]
>
>

[Owen Waldrep]

I am not sure how old this post is and whether this was not possible in past versions but I have disabled items in a RadioButtonList this way:
rblEditRegistrations.Items(0).Enabled = False

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 [url]http://staff.develop.com/onion/resources.htm[/url] 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
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcontemplateddataboundcontrolsample.asp[/url]
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

[kolleen.koby]

I would start by installing Firebug in Firefox and using its NET panel to look at exactly what is being posted to the server. The NET panel has a POST tab that will show you everything that's being sent. And yeah, that probably does include viewstate.