Looping through CheckBoxList items doesn't pick up selected ones when items were disabled

[Bart Van Hemelen]

The situation: I have a CheckBoxList cblTest, the items are disabled in
cblTest_DataBound in a foreach (ListItem oItem in cblTest.Items) loop.

I provide a link that calls a client-side JavaScript that enables the
items -- this works perfectly. However, when I then click a LinkButton
that does a postback and I loop through the items on serverside to pick
up the selected ones, it doesn't pick them up. IMHO it seems to loop
though the items as they were saved in the ViewState, not as they were
sent to the server.

The real problem is that the CheckBoxList is inside a UserControl that
is used inside an Atlas UpdatePanel, so my original solution wouldn't
work: I decided to disable the CheckBoxList-items on the clientside,
but of course after the UpdatePanel updates, it doesn't fire that
client-side code again and so the items in the CBL remain enabled
(which shouldn't be) and AFAIK there isn't a way to force it to do so.

IMHO the only "solution" would be if there were a way to force the
code-behind to ignore the viewstate of the CheckBoxList when looping
through the items after a postback, but AFAIK there is no way top do
that (unless I am mistaken).

I've noticed a couple of older posts, dating back to 2004 (!) where
developers describe similar problems. So if this is a bug, why wasn't
it solved? Does anyone have a working workaround?

Tools and technologies used: Visual Studio 2005, asp.net 2.0, C#.

--
BVH

[bruce barker \(sqlwork.com\)]

the underlying probem is that a browser will not postback a disabled fields.
also checkboxes will only postback their value if checked. thus from the
servers side is impossible to tell a disabled postback from a unchecked
postback of a checkbox.

asp.net solution is to remember (using viewstate) that a control was
disabled at render time and what its value was so it can be restored at
postback.

if you want client script to play with enable/disable you will have to come
up you own solution (usually using a hidden field the client script passes
additional state info to the server) . turn off viewstate support on a
control to disable the standard serverside handling.

-- bruce (sqlwork.com)

"Bart Van Hemelen" <ba************@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

The situation: I have a CheckBoxList cblTest, the items are disabled in
cblTest_DataBound in a foreach (ListItem oItem in cblTest.Items) loop.

I provide a link that calls a client-side JavaScript that enables the
items -- this works perfectly. However, when I then click a LinkButton
that does a postback and I loop through the items on serverside to pick
up the selected ones, it doesn't pick them up. IMHO it seems to loop
though the items as they were saved in the ViewState, not as they were
sent to the server.

The real problem is that the CheckBoxList is inside a UserControl that
is used inside an Atlas UpdatePanel, so my original solution wouldn't
work: I decided to disable the CheckBoxList-items on the clientside,
but of course after the UpdatePanel updates, it doesn't fire that
client-side code again and so the items in the CBL remain enabled
(which shouldn't be) and AFAIK there isn't a way to force it to do so.

IMHO the only "solution" would be if there were a way to force the
code-behind to ignore the viewstate of the CheckBoxList when looping
through the items after a postback, but AFAIK there is no way top do
that (unless I am mistaken).

I've noticed a couple of older posts, dating back to 2004 (!) where
developers describe similar problems. So if this is a bug, why wasn't
it solved? Does anyone have a working workaround?

Tools and technologies used: Visual Studio 2005, asp.net 2.0, C#.

--
BVH

[Bart Van Hemelen]

Bart Van Hemelen wrote:

The real problem is that the CheckBoxList is inside a UserControl that
is used inside an Atlas UpdatePanel, so my original solution wouldn't
work: I decided to disable the CheckBoxList-items on the clientside,
but of course after the UpdatePanel updates, it doesn't fire that
client-side code again and so the items in the CBL remain enabled
(which shouldn't be) and AFAIK there isn't a way to force it to do so.

I've "solved" this. The .ascx now derives from a custom base class that
derives from System.Web.UI.UserControl, and which implements a couple
of functions which basically only are wrappers for built-in functions
like Page.ClientScript.RegisterStartupScript . By doing it this way,
the disabling/enabling now works 100% on client-side even though I
can't figure out why it didn't when I called
Page.ClientScript.RegisterStartupScript directly from the ascx.

--
BVH