Organizational Research By

Surprising Reserch Topic

reference asp net control by id in javascript

reference asp net control by id in javascript  using -'javascript,,ajax'

When ASP.NET controls are rendered their ids sometimes change, like if they are in a naming container. Button1 may actually have an id of ctl00_ContentMain_Button1 when it is rendered, for example.

I know that you can write your JavaScript as strings in your .cs file, get the control's clientID and inject the script into your page using clientscript, but is there a way that you can reference a control directly from JavaScript using ASP.NET Ajax?

I have found that writing a function to parse the dom recursively and find a control that CONTAINS the id that I want is unreliable, so I was looking for a best practice rather than a work-around.

asked Sep 13, 2015 by JesMathew
0 votes

Related Hot Questions

8 Answers

0 votes

Couple of thoughts on this:

1) I've had a lot of luck getting elements by css class instead of id because ids are not reliable as you stated. I use this function and it performs reasonably well:

function getElementsByClass(searchClass,node,tag) {
 var classElements = new Array();
 if ( node == null )
        node = document;

 if ( tag == null )
        tag = '*';

 var els = node.getElementsByTagName(tag);
 var elsLen = els.length;
 var pattern = new RegExp("(^|\\s)"+searchClass+"(\\s|$)");

 for (i = 0, j = 0; i < elsLen; i++) 
        if ( pattern.test(els[i].className) ) 
                classElements[j] = els[i];
 return classElements;

2) jQuery helps here alot. Using jQuery you can reliably get elements where the id ends with a certain string. While this is not "the" reason to use jQuery it's definitely a plus.

3) This will be fixed in 4.0 so hang in there :-)

answered Sep 13, 2015 by KishaK67qavr
0 votes

This post by Dave Ward might have what you're looking for:

Excerpt from article:

Indeed there is. The better solution is to use inline ASP.NET code to inject the control’s ClientID property:

$get('<%= TextBox1.ClientID %>')

Now the correct client element ID is referenced, regardless of the structure of the page and the nesting level of the control. In my opinion, the very slight performance cost of this method is well worth it to make your client scripting more resilient to change.

And some sample code by Dave from the comment thread of that post:

The comment thread to the article I linked above has some good discussion as well.

answered Sep 13, 2015 by PDLMariisxol
0 votes

You can change to ClienIDMode property of the control to 'Static' that will result the same ID that you give the control in the .NET code.


will result:


so you have the same ID.

answered Sep 13, 2015 by ScottyRobiso
0 votes

Oh, and I also found this, in case anyone else is having this problem.

Use a custom jQuery selector for controls:

answered Sep 13, 2015 by LeliaOdomsq
0 votes

I don't think there's a single "best practice" for doing this. There's plenty of different pretty good practices. Here's ours:

Every control which has client-side functionality renders a script block inline, directly below the markup for the control:

    control markup

Each control has an accompanying JS like:

var CustomControl = function(id) {
    this.control = document.getElementByID(id);

CustomControl.prototype.init = function() {
    //do stuff to wire up relevant events

In the codebehind, we do something like:

class CustomControl : Control

override void Render(HtmlTextWriter writer)
    writer.WriteAttribute("id", this.ClientID);
    //write control markup
    writer.WriteAttribute("type", "text/javascript");
        string.Format("new CustomControl('{0}');", this.ClientID)
answered Sep 13, 2015 by MillaP56bdd
0 votes

I do something similar to Rex M except to avoid multiple script tags I use a function in my page base class to register the controls I am going to use clientside, then spit them out to html inside 1 script tag.

You could even subclass your controls to automatically register with the function or use a boolean property to set whether you are going to use them clientside.

answered Sep 13, 2015 by BuckHaileyvo
0 votes

For 'ctl00_ContentMain_Button1' - In when page renders in the browser, first part remains same 'ctl00'. Second part is ID of ContentPlaceHolder used 'ContentMain'. Third is ID of a control 'Button1'

I liked this

answered Sep 13, 2015 by ThomasIFLAde
0 votes

I prefer data bound tags in the markup document.getElementById('<%#TextBox1.ClientID %>').value, over the use of the server side tag implementation <% = TextBox1.ClientID %>.

Server side tags prohibit you from adding controls to the dom in the code behind. This need commonly arises as you build out your application and the databound approach may save you from major rewrites.

When using server side tags also know as 'code blocks' performing this common operation


generates this error at run time:

The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).

Unfortunately this often only become inherently obvious after you have built out your web site.

When implementing data bound control '<%#TextBox1.ClientID %>' resolve the value of control properties referenced in the markup, in the appropriate place such as the end of Page_Load data bind like this:


Keep in mind Page.DataBind() causes child controls on the page to also DataBind, this may be an unwanted side effect if the page handles the data binding of certain child controls separately. If this is the case, data binding can be performed on the individual control like this:


An applications evolution eventually leads to some sort of base site wide functionality where you may want to add base controls, once you've peppered you website application with server side tags replacing them with databinds becomes problematic, especially when pages have been coded to handle databinding on their own.

answered Sep 13, 2015 by Zak9370