Controls.Add() Problem in ASP.NET 2.0

[Iain Buchanan]

Moving this code below from v1.1 to 2.0... am now getting this bug...

After I bind a repeater I move the repeater inside the placeholder
using controls.add(), but when I do this, all the children's clientids
change - I also ran a test and then moved the repeater again into a
third placeholder, and surely enough the clientid's change further.
The only work around I have found is to bind the repeater again after I
move the placeholder, but that just feels wrong.

// Bind Data
myRepeater.DataSource = new string[4];
myRepeater.DataBind();

// mClientIDBefore is now "myRepeater_ctl00"
string ClientIDBefore = myRepeater.Controls[0].ClientID;

// Move repeater inside a placeholder
myPlaceHolder.Controls.Add(myRepeater);

// ClientIDAfter is now "myRepeater_ctl04"
string ClientIDAfter = myRepeater.Controls[0].ClientID;

 

[jaybeeuk]

Hi -

I have been able to replicate this exactly as you say - very weird!

I can see that this would be a problem with any View State reliant code
that you may use?!

James

 

[Teemu Keiski]

Why don't you just put it to PlaceHolder first (the final place it's going
to be) and then dataBind once? ID changing makes sense. not just ClientID
but also UniqueID since that data is used when routing postback data. If
control is not where it's supposed to be per the ID path, how would
framework be able to locate control?

 

[Iain Buchanan]

Because its being used in a dynamic site where the contents / position
is unknown at design time, The example code in the original post is
purely to prove that there is a potential issue with the repeater, the
original code is too large / complex to post. In the production app,
the control modifications are made during Init/Load/Render events in
order to rebuild the control heirarchy in the same format that it was
originally initialized. However viewstate is not the problem, the
problem is that when the child controls are initially added to the
repeater, the uniqueID/clientID properties are created (I need this
because I override the databind method of the repeater and inject the
clientid's elsewhere), however any re-assignedment of the repeater
forces the child controls to generate new uniqueID, when the only thing
that has changed is the parent property.

My first thought was that it was a heirarchy issue, but I've even tried
moving the repeater to one Placeholder and then back to its original
position (so the page's control heirarchy is exatly the same at time of
databind, however the clientid's are never the same.

Why don't you just put it to PlaceHolder first (the final place it's going
to be) and then dataBind once? ID changing makes sense. not just ClientID
but also UniqueID since that data is used when routing postback data. If
control is not where it's supposed to be per the ID path, how would
framework be able to locate control?

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke

Moving this code below from v1.1 to 2.0... am now getting this bug...

After I bind a repeater I move the repeater inside the placeholder
using controls.add(), but when I do this, all the children's clientids
change - I also ran a test and then moved the repeater again into a
third placeholder, and surely enough the clientid's change further.
The only work around I have found is to bind the repeater again after I
move the placeholder, but that just feels wrong.

// Bind Data
myRepeater.DataSource = new string[4];
myRepeater.DataBind();

// mClientIDBefore is now "myRepeater_ctl00"
string ClientIDBefore = myRepeater.Controls[0].ClientID;

// Move repeater inside a placeholder
myPlaceHolder.Controls.Add(myRepeater);

// ClientIDAfter is now "myRepeater_ctl04"
string ClientIDAfter = myRepeater.Controls[0].ClientID;