Sources of UniqueID and ClientID

In the article "Casual id", the author raises the question of why accessing ClientID in the ItemCreated event can cause MyButton to be unable to respond to an event, in fact MyButton cannot respond to an event because his ID on the client is changed, This article starts from UniqueID and ClientID, carries on the thorough discussion, shows how UniqueID and ClientID are generated, when to generate, and at the same time answers the author's question in the text of "Random Comment ID".

Why are there UniqueID and ClientID?

This I think most people who use WebForm already know, for the most part because of the existence of data-bound controls in WebForm and controls that can have child controls, such as custom controls, view controls, and so on, which makes it very likely that there are 2 objects with identical IDs in the control tree. But since HTML does not allow for the repetition of IDs, WebForm invented a thing called NamingContainer and provided the controls with UniqueID and ClientID attributes that distinguish each other.

Although these two attributes often cause us such trouble, but in general, this is a good design, understandable.

How UniqueID and ClientID calculate

The first thing to understand is that all the controls in WebForm eventually form a tree, and each control is a node in the tree.

In a tree structure, each node has 0 or 1 parent nodes, and UniqueID and ClientID are based on the "path from the root of the tree to the current node" to compute the UniqueID, let's take a look at the following example:

<asp:repeater id= "MyRepeater" runat= "Server" >
<ItemTemplate>
<asp:button id= "MyButton" runat= "Server" text= "my button"/>itemtemplate>
Asp:repeater>

We placed the mybutton in the MyRepeater, and this simple content generates the final HTML of this mybutton as follows:

Notice that the button's ID changes to Myrepeater_ctl00_mybutton,name and it becomes Myrepeater$ctl00$mybutton, which is exactly the ClientID of the server-side control, as described in the "Casual ID" article. And name is exactly the UniqueID of the server-side control.
What we're going to explore now is why IDs will look like this, so let's start with the literal understanding that we can't see:

In this ID, there is the word "myrepeater", which is exactly the mybutton of the parent element repeater server-side ID in the middle of the word "ctl00", according to our programming habits, the CTL should indicate the meaning of control, and 00 Natural is the index, This means that "this MyButton is the 1th element in the list produced by repeater (subscript 0)" and the Last word "MyButton" is exactly the MyButton server-side ID

Well, after decomposing the IDs, we can understand the ClientID generation strategy very clearly:

The method for generating ClientID is to precede the ID of the control itself with the index of the control in the data binding (if any) plus the ClientID of the parent control

So how does this happen, here is the concept of NamingContainer, for NamingContainer, only need to implement a tag interface INamingContainer.
When the control evaluates ClientID, it looks for whether the current control's NamingContainer property is null or not, and if not, calls a method called Getuniqueidprefix of the NamingContainer, which is, of course, recursive. Another Getuniqueidprefix method is invoked in the method body.
As for the NamingContainer this property is how to come, in fact, in the call Controls.Add method added up, you can use the reverse compiler to look at the control class is called the implementation of the Addedcontrol method, this is not to repeat.

Continue >> Next [1th] [page 2nd]