The best way that I know of is to call a control by using the ClientID
property like this:
function doSomething() {
var textBox = document.getElementById("<%= txtUsername.ClientID
%>");
textBox.value = "whatever";
}
This will get you the actual ID of the control as it is rendered on
the client, so your javascript will work. It's actually doing some
server-side work, but it is much easier to look at than doing it all
in code-behind.
You can actually take it a step farther - I've seen code out there
that will automatically take all normal controls on a page and define
page-level javascript variables so you get a one-to-one relationship,
something like the following, outside of any functions:
var txtUsername = document.getElementById("<%= txtUsername.ClientID
%>");
var ddlCompany = document.getElementById("<%= ddlCompany.ClientID
%>");
On Jan 5, 8:19 pm, BBetances <[email protected]> wrote:
> I came from PHP around a year ago. In the past year, i've learned
> quite a bit about the .NET Framework, and believe it has much promise.
> I like the fact that everything is translated into an intermediate
> language, so VB.NET can communicate with C#, and vise-versa. One issue
> I have, though, is ASP.NET's handling of JavaScript. I understand that
> when the HTML is rendered (Just-In-Time), the names of the controls
> change, so adding JavaScript to a control is very difficult. The best
> way I know of is to put the JS in the CodeBehind, and use
> RegisterClientScriptBlock. With PHP, JS and PHP work together on basic
> HTML controls. Now, don't get me wrong; PHP is way too much typing,
> not enough thinking. Implementing a basic SQL authentication control
> could take a few hours, easy. But what I don't understand is, why
> is .NET so incompatible with JS? Running JS at the server kind of
> defeats the purpose, doesn't it?
>
> I'd like to hear your thoughts on this one. I recently started getting
> intimate with jQuery, and this small hangup kind of bothers me.
