Nathaniel Greene
1/24/2007 4:56:00 PM
If you use the ClientID before the control has been added , since strings are
immutable so a copy is made, any where you used the ClientID it will be old
and will not be updated. Unless you can provide code that says this, from
your description of it, this sounds like a by design issue.
This is why it is best to get everybody added to the hierarchy early on so
that there is no changing requied. And should any custom rendering or id
setting be done it be done as late as possible to ensure that anybody that
accidentally did get left behind got caught up.
"Iain" wrote:
>
>
> "Iain" wrote:
>
> > I've a complicated custom control which has been running fine for a year or
> > so. Just recently I've made a change which has stopped it working. But why?
> >
>
> Well, I've discovered the problem and regard it as a bug.
>
> I had a Debug.WriteLine in my code which printed the value of the ClientID.
> This debug line is called BEFORE the container is added to the controls
> collection (and hence before it gets it's own ID).
>
> So it would appear that if you access ClientID before the container is added
> to the control tree, the value is fixed at that. If you later add this
> control to a control collection, the new hierarchy is not reflected in the
> ClientID.
>
> Needless to say I did not expect this. I would have expected the ClientID
> to be updated if the environment which the control lived in (ie it was
> parented or reparented) was changed.
>
> Of course, the whole thing *still* doesn't work, but that's another story!
>
> Moral of the story is - if things don't work take out your debugging code ..
>
> Oh if anyone from MS reads this, could you comment on if this should be a
> bug or not and address it in future releases?
>
> Thanks to all for input.
>
> Iain