Today Ben Feist emailed me pointing out a problem with the DynamicControlsPlaceholder (DCP) and the CheckBoxList (CBL). He always receives a "Multiple controls with the same ID" exception when putting a CBL onto the placeholder.
So I took a look at the implementation of the CheckBoxList and noticed that like the DropDownList and the RadioButtonList (RBL) it is derived from ListControl which contains a ListItemCollection. This collection implements IStateManager and is saved in ViewState. So no need for the DCP to save the single ListItems. Why does it work with the RBL but not with the CBL?
Examining the RBL I noticed that when it comes to the render phase for each ListItem a RadioButton instance is created and written to the output TextWriter directly (see RBL.RenderItem for reference). So the ListItems/RadioButtons are never contained in the Controls collection which is used by the DCP. No problem for the DCP!
However the CBL works a bit differently: In the constructor a CheckBox control is created, added to the child collection (!) and stored in the internal member controlToRepeat. In the render phase for each ListItem the controlToRepeat is modified to reflect the text and checked state and then written to the output stream.
That's the problem for the DCP. At the end of the first request, it loops over the Controls collection noticing the CheckBox and persisting it. After the postback, the CBL constructor creates a new CheckBox again and then the DCP recreation algorithm restores the "same" CheckBox (ID="0" is hardcoded). This causes the duplicate control ID exception.
I wondered why the CBL constructor creates this special CheckBox and to find out I created a MyCheckBoxList with a "this.Controls.Clear()" constructor ;) That solved the duplicate ID problem.
However, Ben pointed out that the MyCheckBoxList does not pick up the SelectedIndex and a quick look at LoadPostData and the HTML source revealed that the NamingContainer was incorrect.
To make a long story short, the CheckBox is added to the child collection so that the NamingContainer of the parent CBL is automatically prefixed to the ListItem index ("[CBLID]_0"). The RBL achieves the same thing manually in the RenderItem method (button1.ID = string.Concat(this.ClientID, "_", repeatIndex.ToString());)
Elegant but not very intuitive - I would expect to find either all ListItems in the control collection or none at all. So, if you ever wondered why the CBL always has exactly one child control no matter how many ListItems there are in your Items collection, you know now.