If I connect a textbox to a watermark control and write client side code like
obj = new Sys.UI.TextBox($('<%=textbox1.ClientID%>'));
it will report Assertion Failed error even if I set ID property for watermark control.
Myabe it is a bug of Atlas.
You're missing a getElementByID. The following works for me:
function foo() {
obj = new Sys.UI.TextBox(document.getElementById('<%= TextBox1.ClientID %>'));
alert(obj);
}
foo();
Hi David, Thanks for your help.
After changing
obj = new Sys.UI.TextBox('<%= TextBox1.ClientID %>');
to
obj = new Sys.UI.TextBox(document.getElementById('<%= TextBox1.ClientID %>'));
I still get same Assertion Failed error.
With my case, this textbox1 is inside an UpdatePanel. In this Updatepanel, I have a button with some ASP.NET code. when Clicking on this button, it only cause partial rendering.
The javascript here only get a string from a popup window. After the code
obj = new Sys.UI.TextBox('<%= TextBox1.ClientID %>');
is executed, and then click on the button inside the Updatepanel, the error came out.
But if code
obj = new Sys.UI.TextBox('<%= TextBox1.ClientID %>');
never executed, everything is OK.
I think the issue here is that the wrapper for hte textbox has already been created, that's why you're getting the assert (for future issues, please paste in the test of the assertion as well, it's usually helpful).
try this code instead:
obj = $object('<%= TextBox1.ClientID %>');
Is there any way to disable the Watermark? I'm getting an assertion error following a postback when I've set the Watermark's target textbox's visible property to false. The error message is:
Assertion Failed: Could not find an HTML element with ID "ctl00_CH_NewFeedTextBox" for control of type "Sys.UI.TextBox".
My code is just a click handler that is setting the visible property of the textbox to false. I'd be happy to set the Enabled property of the Watermark to false as well... if it had such a property.
When you set the Visible property to false, the control isn't rendered at all to the client. Thus, there is no ctl00_CH_NewFeedTextBox control in your client-side page. try NewFeedTextVox.style.display="none" to hide it. This will make it render to the page, but not be visible in the browser.
Hi sburke_msft, If I change the code to
obj = $object('<%= TextBox1.ClientID %>');
then it will report error obj is null.
Here question is I want to use Atlas code and make things simply. If I do not use Atlas code here, just use javascript directly, no this problem.
It means watermark combine orginal javascript, no this problem.
I certainly *could* do that and get past this error, but the point is that the extenders are supposed to add functionality to other controls without requiring me to change how I'm using those controls. Since it is perfectly normal for developers to set the Visible property to false for TextBox controls (and since this is more efficient in terms of rendering time and bandwidth, etc.), the better solution would be to fix the Extender so that it can detect whether the Control it is associated with is Visible, and if not, disable itself. Or, barring that, expose an Enabled property that I can manually set to false when I disable/invisible the control it is targeting.
Agreed. However to be overly blunt, before a fix comes out, you have only ( as far as I know, correct me if wrong ) 2 options: write your own extender, or use the display property.
This has come up several times. As pointed out here, Visible=false means that the control isn't rendered, so there's no way the client side code can handle it.
We've talked about possible solutions, but none of them are automagic and still reasonable:
1) We could flip the visible bit and add display:none via the extender - this could expose security issues by rendering code that wasn't intended to be
2) We could throw an exception - this means you still need to make this change to your HTML
3) We could do nothing - this makes it pretty hard to debug and people waste time trying to figure out why X isn't working.
So at the end of the day, yes, you need to make a markup change here. Our goal with extenders is to allow you to do as much as possible without modifying the original page but there are many, many scenarios when this just simply isn't possible.
Hope that helps.
In my scenario, the request I would have is that the extender expose an Enabled property (or Visible, but since most of them aren't really visible to begin with, Enabled is more intuitive). If I *know* that I'm writing some code that is going to take the target of the extender away, then that gives me the developer to option of turning off the extender in that same chunk of code. Meanwhile, everything else works as before.
I know I'm going to have to write code for this situation to work out. That's ok - that's not my point. What I'm going for is the best implementation for the Extender controls.
The question is, would I rather
A) Write some CSS code to hide my textbox when I have years of experience, best practices, and thousands of lines of code showing me that to do this I set Visible to False.
or
B) Modify the control that I've just added to the page, the one that I'm already having to touch anyway, the one that is bombing out, and the one that has as one of its core advantages the lack of necessity to touch its target control.
My vote is B. The code for this should be simple -- wrap the control's inner workings in a big if(this.Enabled) statement.
Thanks - I hope that clearly makes my point/recommendation.
I guess my underlying question, which I'll make explicit here, is:
Whynot have an Enabled property on Extender controls to enable/disable their behavior?
Actually this has been solved - I forgot that we did make a change here. Make sure you have a new Toolkit build.
If the target control isn't Visible, we simply don't emit the hookup, so nothing happens. Once it becomes visible, we'll generate the hookup and it'll start working.
