In ASP.NET a Control has a fully qualified id that can be deduced from the control hierarchy and can be accessed with the properties ClientID or UniqueID. It then becomes the unique id or name of rendered html controls. It makes sense that these properties should be used right after the control hierarchy is completely defined, that means before the rendering, therefore in the PreRender.

What is not so well known is that accessing those two properties sets the _cachedUniqueID member, which sets irrevocably the ID to a control. That's why using these properties in ItemCreated events, for example, makes the html id of controls to remain the default defined one.

Example: In a DataList, you have an item template that contains a control, let's call it Control1. The rendered id in html will look like this: ctl00_ContentPlaceHolder1_UcUserControl_DataList1_ctl00_Control1 , but if you use ClientID inside the DataList_ItemCreated event, the rendered html id will be just Control1, thus making any javascript manipulation futile.

Of course, one could create a method to return the UniqueID without setting the cached value, since there are moments when the partial hierarchy is enough to define a proper id. Unfortunately, for controls without a specific and declared id, ASP.NET creates and automatic ID like ctl[number] or _ctl[number] and, of course, those methods and fields are all private or internal. One could use Reflection to get to them, but what would be the point?
UniqueID and ClientID are overridable, though, so one can change their behaviour in user defined controls.

Related links:
Accessing ClientID or UniqueID too early can cause issues

Comments

Be the first to post a comment

Post a comment