My application calls for a lookup table in which the user can add records.
When the application is run, an html table will be created dynamically to
show checkboxes (and .Text) for each of the values stored in the lookup
table. The checkboxes will be checked/unchecked depending on data in
another table.

The challenge is how to display the html table on first load AND displaying
the html table on postback while maintaining its view state. Here's my
battle plan:

1. Regardless of Postback: build the html table dynamically depending on
records in the lookup table.
2. if not PostBack: get a handle on the controls and set the
checked/unchecked values accordingly.
3. if is PostBack: nothing more. The viewstate should be maintained IF care
is taken regarding the order in which the dynamic controls are added and
their properties are set (ref:
http://scottonwriting.net/sowblog/posts/2152.aspx).

I'm reasonably comfortable that this will work. Regardless, the purist in
me is not comfortable rebuilding the dynamic html table in step #1 upon
postback. Ideas?

"J" <nobody> wrote in message
news:a02f
> My application calls for a lookup table in which the user can add records.
> When the application is run, an html table will be created dynamically to
> show checkboxes (and .Text) for each of the values stored in the lookup
> table. The checkboxes will be checked/unchecked depending on data in
> another table.
>
> The challenge is how to display the html table on first load AND
> displaying the html table on postback while maintaining its view state.
> Here's my battle plan:
>
> 1. Regardless of Postback: build the html table dynamically depending on
> records in the lookup table.

Yes.

> 2. if not PostBack: get a handle on the controls and set the
> checked/unchecked values accordingly.

Yes.

> 3. if is PostBack: nothing more. The viewstate should be maintained IF
> care is taken regarding the order in which the dynamic controls are added
> and their properties are set (ref:
> [..]).

Didn't read the link, but in general, yes, viewstate is maintained for
dynamic controls.

> I'm reasonably comfortable that this will work. Regardless, the purist in
> me is not comfortable rebuilding the dynamic html table in step #1 upon
> postback. Ideas?

Why are you not comfortable rebuilding the dynamic html table in step #1 on
postback?

first of all, you should not use viewstate unless this is a local
intranet app. turn it off, or your payload will be too large and pages
will be slow.

all content in asp.net is dynamic, you just don't see the code that
creates the objects and adds then to the controls collection, but its
there.

if you use viewstate the html is not stored, but rather every property
of every control is sent to the browser in a hidden field. viewstate
does not create any controls, rather because the control stores all of
its property values in the viewstate collection, loading viewstate
initializes all the values.

common property code:

public string Text
{
get
{
string str = (string) this.ViewState["Text"];
if (str == null)
{
return string.Empty;
}
return str;
}
set
{
this.ViewState["Text"] = value;
}

}

on postback you should recreate the table and controls in the oninit
routine so the controls can load their postback data. be sure the
controls and any naming containers get the same id. unless you need the
before value to fire onchange, there is no need to initial the text
values in oninit.

-- bruce (sqlwork.com)

J wrote:
[..]

"Scott Roberts" <sroberts> wrote in
message news:4284
>
> "J" <nobody> wrote in message
> news:a02f
>
> Yes.
>> Yes.
>> Didn't read the link, but in general, yes, viewstate is maintained for
> dynamic controls.
>> Why are you not comfortable rebuilding the dynamic html table in step #1
> on postback?

It seems like duplicate logic where there might be a cleaner way to just
pass data to rebuild it. The purist in me doesn't like to do the same work
twice but I guess that's nature of the beast.

"J" <nobody> wrote in message
news:159c
> "Scott Roberts" <sroberts> wrote in
> message news:4284
>
> It seems like duplicate logic where there might be a cleaner way to just
> pass data to rebuild it. The purist in me doesn't like to do the same
> work twice but I guess that's nature of the beast.

As Bruce mentioned, *all* server-side controls are re-created on postback.
The ones declared in the aspx are done automatically, but it's really the
same thing. Furthermore, I'd say that this is the "cleaner" method. If you
were to somehow serialize your controls then de-serialize them on postback
you'd actually incurr more overhead than simply re-creating them
dynamically. You may want to cache the *data*, but not the controls.