Reference ASP.NET control by ID in JavaScript?

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.

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

http://encosia.com/2007/08/08/robust-aspnet-control-referencing-in-javascript/

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:

<script>
  alert('TextBox1 has a value of: ' + $get('<%= TextBox1.ClientID %>').value);
</script>

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

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

<asp:TextBox ID="TextBox1" ClientIDMode="Static" runat="server"></asp:TextBox> 

will result:

<input name="ctl00$MainContent$TextBox1" type="text" id="TextBox1"> 

so you have the same ID.

Couple of thoughts on this:

1. I've had a lot of luck getting elements by css class instead of id because asp.net 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]; j++; } } 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 asp.net 4.0 so hang in there :-) <http://weblogs.asp.net/asptest/archive/2009/01/06/asp-net-4-0-clientid-overview.aspx>

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:

<span id="something_crazy_long">
    control markup
</span>
<script type="text/javascript">new CustomControl('something_crazy_long');</script>

Each control has an accompanying JS like:

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

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.WriteBeginTag("span");
    writer.WriteAttribute("id", this.ClientID);
    writer.Write(HtmlTextWriter.TagRightChar);
    //write control markup
    writer.WriteEndTag("span");
    writer.WriteBeginTag("script");
    writer.WriteAttribute("type", "text/javascript");
    writer.Write(HtmlTextWriter.TagRightChar);
    writer.Write(
        string.Format("new CustomControl('{0}');", this.ClientID)
    );
    writer.WriteEndTag("script");
}

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.

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

Use a custom jQuery selector for asp.net controls: http://john-sheehan.com/blog/custom-jquery-selector-for-aspnet-webforms/

For 'ctl00_ContentMain_Button1' - In asp.net 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 http://codedotnets.blogspot.in/2012/01/how-get-id-server-control-javascript.html

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

> this.Form.Controls.Add(myContorl);

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:

> Page.DataBind()

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:

> TextBox1.DataBind()

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.

You can get the ID by using document.getElementById method as well.