Short Story:This will not work:
<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="MyNumberInput.decreaseValue();" />
This is how to correct it:
<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="window.MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="window.MyNumberInput.decreaseValue();" />
Long Story:This will work:
<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="increase();" />
<script type="text/javascript">
function increase()
{
MyNumberInput.increaseValue();
}
</script>
But, as mentioned before, this:
<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();"/>
will instead produce a JavaScript error:
MyNumberInput.increaseValue is not a functionBut isn't that the exact same code?? What is going on?
It turns out that in the second case "MyNumberInput" is not referring to the client-side NumberInput object. Instead it is referring to a DOM element of the same name.Like most ComponentArt controls, input controls create a number of client-side DOM elements and JavaScript objects.
In this particular example, with a NumberInput named MyNumberInput:
In JavaScript, the most important object is named
MyNumberInput, and is an instance of client-side class
ComponentArt.Web.UI.NumberInput.
In the DOM, there are a number of different elements, including a text input with the id
MyNumberInput.
This results in a very unusual naming conflict. Normally, when you write
MyNumberInput in client-side code, you expect it to refer to the global JavaScript object of that name. And it does.
Except when the code is running in the event handler of an HTML tag. Then
MyNumberInput refers to the DOM element with that id. Which is probably not what you want.
To avoid ambiguity, you can use
window.MyNumberInput to refer to the JavaScript object, and
document.getElementById('MyNumberInput') to refer to the DOM element.
So why don’t we fix this? Well, it turns out that there is no real bug here.
First of all, this is not a design that is unique to ComponentArt input controls. In fact, most ComponentArt controls produce JavaScript objects and DOM elements with matching identifiers, for a number of reasons. What is different with input controls is that the DOM element in question happens to be a form element. This triggers the naming conflict.
However, having these matching identifiers turns out to be needed for the input controls to work smoothly with ASP.NET’s client-side validation, which is a very important feature.
So it is unlikely that we will be able to "fix" this. Instead, just please keep this gotcha in mind.
