The most viewed blog post I've written by far is Don't use GetType() with Page.ClientScript.RegisterClientScriptBlock(). It's attracted a few comments, so it seems ripe for a followup post.
Commenter Sander asked "Page.ClientScript.IsClientScriptBlockRegistered()
comes with two overloaded variants. One is without type and other is with type. Any idea how this IsClientScriptBlockRegistered(key) cheks if script is registered?"
Good question - easily resolved with Lutz Roeder's invaluable Reflector (although if you're squeamish about license conditions regarding decompilation of .NET assemblies - or you work on the Mono codebase - you may want to look away now). The overload of IsClientScriptBlockRegistered without a Type parameter calls the other overload for you passing typeof (System.Web.UI.Page) as the type parameter. I wouldn't rely on the behaviour though - if you register a script passing typeof (Page) and then subseqently call IsClientScriptBlockRegistered without passing a type parameter, your code runs a heavy risk of breaking in a subsequent version when the undocumented behaviour is changed. Best to just employ the variant that takes a Type parameter and have done with it.
David Jorgensen asked "how about using reflection to get the current type?? ie: System.Reflection.MethodBase.GetCurrentMethod().GetType();"
Well, indeed, that will work. But unless your code is operating in a very unstable CLR environment, where something very peculiar is reaching into the appdomain and tweaking classes around on the fly (I'm struggling to think of any real examples - perhaps profiling software or something), then there are no realistic circumsances where System.Reflection.MethodBase.GetCurrentMethod().GetType() won't end up giving you the same exact object that typeof (TheClassThisCodeIsIn) does.
Actually, I tell a lie. If you call MethodBase.GetCurrentMethod().GetType() inside, say, an anonymous delegate or an iterator body, then you may well get a type object representing a freaky C#-compiler-generated type. But that's all the more reason not to do it. You don't want to know what the C# compiler is doing to make your iterator work, you really don't.
And remember, typeof () is resolved into very simple IL operations, whereas MethodBase.GetCurrentMethod().GetType() is a chain of method dispatches into the System.Reflection assembly with who-knows-what security checks, stack-walks and assembly metadata lookups to perform. There's no way it'll be as fast, and it's just going to get you the same object in the end.
Commenter Brandon asked "Why on earth would you ever make one ascx control inherit from another?", but as fellow commenter Chris pointed out, nobody mentioned ASCX controls. In fact, it's not so much a question of 'why on earth you would want to' - acually, there are perfectly good reasons for wanting to make a control inherit from another one, and they apply equally to ASCX controls as to custom controls - but in fact more that you can't create a control that inherits from an ASCX user control in ASP.NET, so the situation doesn't arise.
But it does raise an interesting point of its own - if I'm writing code inside a <script runat="server"> block on an ASCX control then I actually have no idea what type ASP.NET is going to cook up for me when it compiles the ASCX code into a class. That means I can't use a typeof() expression to identify the current type. In that situation, I guess I would accept a call to this.GetType() as the only valid way of getting hold of the type, but that's a pretty unusual scenario (I can, however, use typeof(TheClassInMyCodeBehindFile) if I'm using the code behind model, so that solves that probnlem for most sane people who use code behind files).