Between April 1998 and December 2001, I was granted a 1000-word monthly soapbox on the back page of a competitor's magazine for Office developers. The chance to rant, complain, chastise, and otherwise blab on any topic that crossed my path each month was a privilege, and some readers even found it mildly amusing. That magazine is now defunct, or at least so modified that no one would recognize it, and my column was unceremoniously dumped soon after the terrible world events of September 2001. I've missed the chance to stand on my soapbox ever since, and when the editorial staff of this vastly more alive publication offered me the opportunity, I jumped at the chance.

Just to get you up to speed: the basic structure of these things is highly predictable. For the most part, each edition starts with a story (normally with a moral) followed by some loosely connected bit of developer-based trivia. Following the loose connection can often be tricky, but if you really work at it, there's always some link. I often gossip about other writers in the magazine, or speakers at conferences, public figures, or events in the news. Everything is fair game.

This month, our story starts with two young developers (ok, "younger than today," not "young"): your intrepid author, and his frequent collaborator and co-conspirator, Paul D. Sheriff. It's August of 2000, and we're digging hard into the alpha version of this new Microsoft .NET thing. Seizing upon what seems an obvious money-making opportunity, we conspire to set up a Web site where we'll post tons of useful tips, walkthroughs, how-to's, and so on, and people will pay us tons of money for the opportunity to download and learn from our immense wisdom. Little did we know that (a) we weren't all that wise and, (b) everybody else was planning the same thing, except for free. Not knowing any better, we marketed the site, both in print and in e-mail?the name of that Web site appeared on many slide decks I used for conference talks during this period, and on e-mail threads floating around the Web. After several months of attempting to craft material for the site, then letting it languish for another few months, it came time to renew the domain name. My co-author, in a moment of uncharacteristic frugality, decided not to renew the name. And so the terror began.

Little did we know that there are vultures out there, awaiting unsuspecting domain owners, ready to latch on and grab any used domain name that goes up for grabs. Within days?nay, within minutes?of Paul letting the lease on the domain name lapse, it was grabbed up for, well, unseemly pursuits. I won't post the original URL here (its current contents are guaranteed to offend many readers), but let's just say that the current owners of the domain name are in a very different business than Paul and I, yet they're probably making a lot more money than we ever did or could have.

The moral of this particular story: Once you license a domain name, it's yours forever. If you ever let it go, you will never get it back. And most likely, you won't like its destination minutes after you neglect to pay the fee. We've learned our lesson, and hope you learn from the errors of our ways. The bad guys inherited our name, and took it in a direction we hadn't intended. (If you're desperate to see what happened to our innocent domain name, drop me a line; I'll send it to you. Be afraid. Be very afraid.)

Speaking of inheritance (see how that works?), I've been having the greatest time lately adding features to Windows Forms controls using inheritance. I hang out a lot at http://www.windowsforms.com (and so should you, if you develop Windows applications with .NET), and answer questions on the public forums there. I learn a lot in the process, and recently, a spate of questions has come up in which people ask, "How do I <x> with the <y> control?" In most cases the answer is the same: Create a new class or control that inherits from the base control class, and expose information that's otherwise set as protected in the base class. As you probably know, members marked as protected are available only in the original class, and in classes that inherit from the class. The designers of the .NET Framework exposed a great deal of functionality in this way, but to get at it, you must inherit from the class.

For example, someone recently asked how you could restrict the size of a CommandButton control at design time. That is, he wanted to be able to allow developers using the CommandButton control in his shop to only create buttons that are sized so that the height is between 50 and 200 units, and the width is between 25 and 100 units. There's nothing public available in the System.Windows.Forms.Button class that allows this, but there is a protected method, SetBoundsCore, that allows you to intercede as the control is moved or sized, and tell the designer exactly how you want the control to work.

To use SetBoundsCore, you'll need to create a new class that inherits from the Button class. Simply add a new class to your project, give it a new name (I'll call mine ButtonMaxSize), and have it inherit from the Button class, like this:

Public Class ButtonMaxSize
    Inherits Button

End Class

You can, if you like, create a new control that includes this class, so you can add it to the Controls toolbox, but I'll leave that as an exercise for the reader.

If you investigate the SetBoundsCore method in the .NET Framework Help, you'll see that it accepts a number of parameters indicating the current coordinates and size of the control, along with a parameter of type BoundsSpecified, an enumerated value that indicates which of the coordinates has been changed (All, None, Height, Width, Location, Size, X, Y). Your job is to determine which coordinate has been changed, and if it's the Size coordinate, ensure that the current coordinates are within the correct bounds. Once you've adjusted the coordinates, your code must call the base class' SetBoundsCore method, passing in the new coordinates.

It's simple stuff, but it's only possible because .NET supports inheritance. I wrote up a simple demo of this behavior:

Protected Overrides Sub SetBoundsCore( _
 ByVal x As Integer,
 ByVal y As Integer,
 ByVal Width As Integer,
 ByVal Height As Integer,
 ByVal specified As BoundsSpecified)

    If specified And BoundsSpecified.Size Then
        Width = Math.Min(Width, 200)
        Width = Math.Max(Width, 50)
        Height = Math.Min(Height, 100)
        Height = Math.Max(Height, 25)
    End If
    MyBase.SetBoundsCore(x, y, _
       Width, Height, specified)
End Sub

To test the class, I created a simple form and placed a standard Button control on the form. In the form's code, I replaced all instances of "System.Windows.Forms.Button" with "ButtonMaxSize," and tested it out. As I expected, I was no longer able to size the button at design time larger than 200 by 100, or smaller than 50 by 25. This is cool stuff! I've run across at least three or four other fun examples of this technique?inheriting from a base control class to enhance its functionality?and I'll try to show off a few more in the coming months.

What have you learned this month? In short, inheritance is really cool when it comes to Windows Forms controls. In addition, once you license a domain name, don't let it lapse?you never know who's waiting in the wings, hoping to "inherit" the name from you. Unlike inheritance using controls, domain name inheritance is rarely cool.