I have developed a simplified test page that consumes this
new extender. There are two tests; the first test targets a button and sets up
the text box as the receiver of the enabled status toggle. Every time the
button is clicked, the disabled status flips its state accordingly.
Listing 12
<asp:TextBox ID="txt1" runat="server" />
<asp:Button ID="btn1" runat="server" Text="First Test" CausesValidation="false"
UseSubmitBehavior="false" />
<n:ButtonEnabledExtender ID="ext1" runat="server" TargetControlID="btn1"
ReceiverControlID="txt1" />
This scenario produces the screenshot below. I produced
these screenshots with the tool SnagIt; this is a very popular and very productive
tool.
Figure 1
In the second scenario, the extender does not target a
textbox as a receiver, it simply defines the button as the target. Notice the
ReceiverControlID is not specified.
Listing 13
<asp:TextBox ID="txt2" runat="server" />
<asp:Button ID="btn2" runat="server" Text="Second Test" />
<n:ButtonEnabledExtender ID="ext2" runat="server" TargetControlID="btn2" />
Rather than toggling the textbox enabled status, this test
prevents a double-click, as shown below.
Figure 2
In both cases, the script changes the state of some UI
element; in the first case, it works with the textbox control, whereas the latter
case the button itself. All of this happens on the client side and works
seamlessly with JavaScript. Deployment is seamless also because this custom
script is stored as an embedded resource in the DLL, and retrieved at runtime. No
code is necessary to perform this action.
