One of my favorite aspects of the AJAX Control Toolkit is that we were given not only a fully functional web app detailing all of the controls, but also the full source code. As a home-grown .NET developer, exploring the source code of the tool / control I am dealing with is a new and fantastic experience. My inner (and sometimes outer) monologue when working with other people's code is usually as such:
"Why the hell did they do that?"
...peruse source code...
Here's the scenario I encountered: The animation framework included in the AJAX Control Toolkit (ACT heretofore) handles typical events to kick off animations (clicks, hovers, etc.) Of course, I needed to work with onmouseup to show an animation as the user dragged-and-dropped over a region; this was not supported.
My first approach literally entailed going into the source of the ACT, copy and pasting the code for the click mouse events across half a dozen files, pasting them verbatim, and doing a find-and-replace from "click" to "mousedown." I recompiled the ACT, copied the new DLL to my project, and it actually worked. The problem then is that, ultimately, we will be dealing with multiple versions of the ACT DLL on our server, and other maintenance nightmares.
Unless you are really into parsing fully-qualified assembly names, commenting lines in and out of web.config files, and renaming "AjaxControlToolkit.dll" to "AjaxControlToolkit.dll.old.modified.june13version.dontusethisfile," then we need a better method to extend these controls – ESPECIALLY if we are deploying our code to an environment like SharePoint.
Finally, TargetControlType specifies what your class can extend. For broader concepts (like animation) this is opened up to all web controls. However, for more specific functionality, (such as Collapsible Panels) you can speficy "Panel" as the target control type. If violated, this is what throws the familiair "This type can't extend controls of that type..." AJAX exception.
All you have left to so is implement your extensions. Mostly, on the managed side of things, this entails declaring properties, helper methods, etc. All of the "work" (in terms of UI elements) is done on the client side. The server side class' job is really instead to initialize, wire, and host.
Everything that happens in the class you are inheriting from is happening here as well. If your base class has a button in it somewhere and a click event is wired up to it, you've got all that going on in your prototype.
So think back to my initial problem: there weren't enough events being handled in the animation framework. So in my derived class, I merely add those events; the ones in the base class still work normally!
There is a project type in Visual Studio 2008 that does most of this for you, but it's good to go through it once from scratch to understand everything going on. Have fun!