Here's something you may not know about the TextboxWatermark Atlas Control. If you use the normal server-side control as depicted in the samples, the control will clear the watermark text from the textbox before submitting the form if the user hasn't added a value. Which is good. But if you add the TextboxWatermark client-side, it will submit the watermark text as the textbox's value. Which is bad. The rest of this post outlines why this happens so skip it if you don't care.

The TextboxWatermarkExtender class will loop through the Extender and register a little bit of javascript for each watermark control in the extender. One of those pieces is to register an OnSubmit statement which means that the script it's registering will get executed just before the form containing the textbox gets submitted.

The script is just a call to the watermark's onsubmit function in the main javascript file for it. That onsubmit function is pretty basic:

this._onSubmit = function() {
   var e = this.control.element;
   if(_watermarked) {
      // Clear watermark text before page is submitted
      _clearedForSubmit = true;

That is, if the textbox is watermarked, clear the text from it before submitting the page. This is so that you don't submit the watermark text as the textbox's value.

As I mentioned, the code that registers this OnSubmit statement is in the TextboxWatermarkExtender class. This means it is included whenever you use the <atlasToolkit:TextboxWatermarkExtender> control in your aspx page.

It also means that if you are registering your textbox watermark control client-side, you do not get the benefit of this functionality. Because you aren't using the <atlasToolkit:TextboxWatermarkExtender>. you are, I'm guessing, bypassing the Extender class and going straight to the underlying javascript.

You can see this behaviour in action by simply clicking the Search button at the top without putting in a search string. Because I'm adding my watermark client-side, you'll get the search results for the term "Enter a search string". If I were to use the server-side TextboxWatermarkExtender control, I'd get whatever behaviour happens when you search for an empty string in dasBlog.

But of course, I shan't be using the server-side control. My workaround for my blog will be to do nothing. The fix affects only those users who want to search for an empty string for Jayzus' sake. Like I've always said: you can't save everybody.

This came up while working on Flamingo and there, I don't have the luxury of assuming an empty string search will be meaningless. My fix is going to be to use the server-side control because the only reason I had the client-side control in there is to see if I could do it.

If you truly want a solution that you can use client-side, here's a rough draft of something that might work. Create a javascript function that calls the _onsubmit for each watermark object on the form. Doubt you'll be able to do that by iterating through a collection if you have more than one. You'll probably have to call the _onsubmit function for each one manually. Here's how you do it (copied straight from the control's source):

   var o = Sys.Application.findObject('<id of watermark object>'); if(o) { o._onSubmit(); };

At the end of this function, add: return true;

Next, you'll need to wire this function into the form's onsubmit event:


form id="form1" runat="server" onsubmit="javascript:return mySubmitFunction( );">

This whole thing is essentially what the extender class does for you. You have other alternatives to registering the submit function. A javascript call to document.forms[0].attachEvent anywhere on the page will probably work, at least in IE. I think the mechanism for attaching events is different in Firefox and Safari. You can also make your own call to Page.ClientScript.RegisterOnSubmitStatement but if you're doing that, you may as well use the server-side control anyway and avoid this mess.

Finally, this doesn't affect all the controls in the Atlas Toolkit. Most of them don't register client scripts in their Extender classes. I had a quick look through a few of them and didn't see any others, in fact. Which makes sense. It'll be necessary anywhere you need to alter the value of a form before submitting it and few of the controls do this.