I wanted to design a utility class that provided some bit manipulation methods for enums with [Flags].  Ideally I wanted to embed these methods directly in the enum definition like I can do in Java, but no such luck in C#.  So the helper class seemed like the next best thing.

Turns out this is pretty hard to do!  You can't build a class with the constraint where T : Enum, for example.  Bill Rodenbaugh comes close in his enum helper class, Enum<T>. 

But when all is said and done, using the helper class doesn't really improve upon readability, efficiency, or even number of characters typed!

Here's a sample using the helper class:

I always forget exactly what I need to do to implement IPostBackDataHandler correctly, so I'm tracking the steps here for future reference.

1. Implement the IPostBackDataHandler interface.
2. Override OnPreRender call Page.RegisterRequiresPostBack(this);.
3. Override Render and write the form fields you need posted back.
4. In LoadPostData, grab the data you posted back.  The postDataKey arg is the same as the ClientID and is generally not useful.

OK, so chances are you know the differences between ID, ClientID, and UniqueID when it comes to ASP.NET controls.

So if you're rendering your own control from scratch, what type of HTML do you emit?  Do you render the ID, the ClientID, or the UniqueID?  The answer depends on what you plan on doing with the control.

For controls that don't worry about postback, you're generally fine with just the ClientID:

writer.write("<div id='{0}'>", ClientID);

But what about when you need to communicate the action of a control back to the server and you want to leverage the FindControl method?  Finding a control based on a client ID is going to fail, since FindControl operates based on unique IDs.

The solution for this circumstance:  render both ClientID and UniqueID.  It's convention to use the name attribute when rendering the UniqueID.

writer.write("<div id='{0}' name='{1}'>", ClientID, UniqueID);

Now when you want to track the state of a control and inform the server of it on postback, you can use the unique ID on the client side:

document.forms[0].hiddenField.value = target.name;  // tracks the unique ID

... and use it to get back the control on the server side:

Control control = Page.FindControl(Request.Form["hiddenField"]);

Note that there is an underlying ASP.NET infrastructure that handles events, with methods such as ClientScriptManager.GetCallbackEventReference(), which may also come in handy depending on the situation.  In my case, I rarely use the .NET infrastructure and instead favor the greater control over managing postback events manually.

I'm just getting started with the YUI JavaScript framework.  My first task was to wrap YUI TabView control with an ASP.NET control so I could easily design and manage it from the server side.  Part of this task involved tracking the selected tab. 

It's easy enough to hook the appropriate event:

new YAHOO.widget.TabView('id').addListener('activeTabChanged', tabViewChangeHandler);

But how do I, from the handler, get a reference to the YUI TabView object?  I need a reference to the object so I can get its ID and the set a hidden field to record the currently selected tab.

As it turns out, the this keyword conveniently enough references the TabView object within event handler functions.  Cool!  So recording the selected tab in a hidden field is pretty easy:

I installed Windows Desktop Search--with some reluctance--after Outlook 2007 kept prodding me to do so.  Traditionally I've used Google Desktop Search without issue, but I didn't have either installed on this particular machine and decided to give Microsoft's search a try.

One big surprise:  it completely replaces Windows' built-in Find Files & Folders feature that's integrated with Windows Explorer.  I like that Microsoft has provided a rich client UI (as opposed to Google's web-based one), however actually replacing an OS feature is a little hard to justify, especially when it removes some functionality.  In this case, my ability to find files and folders by name is now limited.  If I search for "notepad.exe," for example, I get a "Nothing found in All Locations" message.  Hmmm... Not cool.  (Actually, it looks like if I "click here to use Search Companion" I get the old functionality.  Not really intuitive!  Why didn't Microsoft just add another button to the Explorer toolbar for "Desktop Search" and keep the existing "Search" button working the way it was, or at least provide both search options in the shell namespace tree?)

At any rate, dropping to the command line provides a decent enough workaround, and is probably faster than the Windows UI anyway:

dir /s notepad.exe

Windows Server 2003 provides support for volume mirroring.  To get this set up correctly, you need at least two physical disks.

• The first disk (I'll call it "disk0") must be a dynamic disk.
• The second disk (I'll call it "disk1") must be a dynamic disk.
• Disk1 must have unallocated space at least the size of the volume you intend to mirror.

Seems simple enough.  However, when I opened the Disk Management MMC snapin, clicked "Add Mirror" on disk0, and chose disk1 as the target, I got this error message:

Cannot mirror to a disk with a different partition style.

Both disks were marked as "dynamic," so I wasn't sure what Windows was complaining about.  But when I right clicked on disk1, I was able to convert the disk from dynamic to MBR.  After making this choice, it worked.  Moral:  there's more to the label "dynamic" than meets the eye.