blue collar

A Few of My Favorite Things...in Visual Studio 2010

2011-03-06T01:46:00Z

Since my last post I've switched from Visual Studio 2008/.Net 3.5 to VS 2010/.Net 4.0 for most of my day-to-day work. I haven't had time to explore them thoroughly, but there are a couple of things that I really like.

The first is that optional parameters have been added to C#. There haven't been many concepts that I've missed in the move from C++ to C# but optional parameters was one of them. No longer do I have to have to write a series of functions to supply default parameters like this:

public void foo()
{
    foo(false);
}

public void foo(boolean onOffSwitch)
{
    ...
}

I can now achieve the same result like this:

public void foo(boolean onOffSwitch = false)
{
    ...
}

The second is the historical debugger. This feature allows you to step back through the events that have occurred in your application to find the context for a failure. There is an episode of the 10-4 show on Channel 9 gives a nice, concise explanation of how to use the feature, so I won't go into details.

A third feature that I find useful is the ability to generate a database from an entity model. I find it much easier to think about the data I need to manipulate as business objects rather than data tables, particularly when I need to model many-to-many relationships. With this feature, I create a new ADO.NET Entity Data Model, design the entities that I need conceptually, and Visual Studio will generate the DDL for creating the database. Now, I'm not a database analyst by profession, so I can't speak to the quality of the generated database; however, for the type of databases I usually need, it works great. Take a look at the Model-First Development with the Entity Framework 4.0 episode of 10-4 on Channel9 or Julie Lerman's tutorial on MSDN.

If you've found features that you like (or don't) in VS 2010, leave a comment to let me know what they are.

Cheers
Dan

DISCLAIMER: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

AssemblyFileVersionAttribute and AssemblyVersionAttribute: A subtle difference

2011-01-12T03:04:00Z

The AssemblyInfo.cs file generated by Visual Studio contains the following lines:

// Version information for an assembly consists of the
// following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Build
// and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

I was trying to auto-increment the build number by changing them like this:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

However, when I looked at the properties dialog for my executable, the file version was "1.0.*".

This puzzled me until I came across Manfred Lange's (Manni on DotNet) very clear explanation of the difference between these attributes and how to use them effectively to auto-increment assembly version numbers. Worth a read.

Cheers
Dan

DISCLAIMER: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

Visual Studio Tip of the Day

2010-11-30T18:06:00Z

I want to give a quick shout-out to Sara Ford and Zain Naboulsi for their great Visual Studio tips. If you use VS in your day-to-day work, you owe it to yourself to browse these blogs: there's sure to be a thing or five that will save you time and effort. I believe there are about 400 tips at present...and new ones coming every day.

Here are a few of my favorites:

Dragging-and-dropping code onto the toolbox's General tab. Discovering this was revolutionary. Whether it's code that I use infrequently (e.g., an implementation of the IDisposable pattern) or something that I know I'll need to insert several times in the next few minutes, it's handy.
Keeping recently used files from falling off the file tab channel. Oh, how I hate to have to find the file I was just using in a dropdown list or Solution Explorer. This keeps files ordered by usage rather than the order they were opened...and saves my sanity.
Pressing Ctrl+D opens the Code Definition window. Until I read this tip, I didn't know there was a Code Definition window. I love being able to view definitions and declarations without leaving the code I'm working on.
Searching for the currently selected string without bringing up the Find window. Now the Find window can't cover the code I need to look at.
Viewing your project in the Document Outline window. I no longer have to scroll through the dropdown in the Properties window to find that control that missing control.
Displaying external function names in the Call Stack window. If, like me, you do a lot of managed/native interop, this is invaluable.
Selecting a box of text. Great for indenting columns in the middle of a table of data.

So thanks Sara and Zain for the great work! Please, please, please keep it up...

As always, please leave a comment if you find this article useful.

Cheers
Dan

DISCLAIMER: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

Poor Man's Guide Lines for Visual Studio's Windows Forms Editor

2010-11-30T05:36:00Z

The custom control I've been working on required drawing custom shapes on each side of the control. The shapes needed to be the same size and I was sure that one was a couple of pixels shorter than the other, but it was difficult to tell with the naked eye. I was wishing that the WinForms editor in VS 2008 had something like Photoshop's Guides: horizontal and vertical lines that can be placed over the image to aid alignment.

Since the real issue was to create an edge that I could use to judge the length of my graphics, I pulled a panel on to the form and stretched it across the control. That worked okay, but the panel was still 8 pixels high and I often had to move it when I resized my form or control. The former was solved easily enough by setting the height of the panel to 1 in the Properties window, but now it was very difficult to get a grip on when I needed to move it. Then it occurred to me that if I anchored the panel to the sides it would stretch as the form stretched. Shazam! Instant guidelines.

At some point I'll write a macro to do this automagically, but this is good enough for now.

If you find this useful, let me know.

Cheers

Dan

DISCLAIMER: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

Why does retrieving resources have to be so difficult? Oops, it's not...

2010-11-01T01:59:00Z

Loading embedded resources at runtime has always mystified me. Should I use the ComponentResourceManager class? Should I try to find the ResourceStream in the assembly? And what's the correct name to use to identify it? Is it simply the file name? Or is it the name of the default namespace plus the filename? Or do I need to specify the assembly name and the filename? And I don't do it often enough to remember how I did it the last time. Arrrrrggggghhh!

Well, I finally realized that I don't need to jump through all of those hoops: any resource that is added to the Resources.resx file can be accessed by name through Properties.Resources. For instance, if I add an icon named Hiho.ico to Resources.resx, I can reference it via Properties.Resources.Hiho. No muss, no fuss!

A couple of things are worth noting here. First, the name that matters is the resource identifier in Resource.resx, not the file name. By default, Visual Studio uses the base file name of the resource as the resource identifier. However, the resource identifier and the file name need not match. For instance, if there is already a resource identifier with that name, Visual Studio will create a new resource identifier by appending a digit to the base file name. Or you might have a co-worker with a perverse sense of humor who decides to rename all of the resources with the names of Disney characters.

The second item of interest (to me, at least) is a bit more esoteric: the resources aren't listed in the assembly manifest. If you simply add the Hiho.ico file to your project and mark it as an embedded resource, you'll see an entry in the manifest like this after you build:

mresource public Foo.Resources.Hiho.ico

However, if you add it to the Resources.resx file without including it as an Embedded object, this line won't appear in the manifest. If you know why this is, please leave me a comment.

Cheers
Dan

DISCLAIMER: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

C# Extension Methods: Syntactic Sugar or Useful Tool?

2010-10-25T06:28:00Z

Last week a colleague introduced me to extension methods (C#, VB) in .Net. If you're not familiar with extension methods, they were added in Visual Studio 2008 to provide a means for adding functionality to existing types without creating a new derived type. Extension methods are called as if they were instance methods of the existing type. For example, if I wanted to know how many vowels there were in a string, I could add a VowelCountEx method to the String class like this:


    static class ExtensionMethods
    {
        public static int VowelCountEx(this String value)
        {
            char[] vowels = new char[] { 'a', 'e', 'i', 'o', 'u' };
            int count = 0;
            foreach (char ch in value)
            {
                if (vowels.Contains(ch))
                {
                    count++;
                }
            }
            return count;
        }
    }

Now the function is displayed by Intellisense as if it was a member function,

and I can then call it like this:


    class Program
    {
        static void Main(string[] args)
        {
            string value = "my string";
            int count = value.VowelCountEx();
        }
    }

(By the way, I’m not advocating appending Ex to the names of extension method: I simply want it to be clear that VowelCountEx is an extension method.)

My initial reaction was ‘Sweet!'. However, after thinking about it for a couple of days (no, my brain doesn’t work very fast), I began to wonder if there was anything more to this than hiding the this reference. I could achieve the same functionality like this:

static class ExtensionMethods { public static int VowelCountEx(String value) { char[] vowels = new char[] { 'a', 'e', 'i', 'o', 'u' }; int count = 0; foreach (char ch in value) { if (vowels.Contains(ch)) { count++; } } return count; } } class Program { static void Main(string[] args) { string value = "my string"; int count = ExtensionMethods.VowelCountEx(value); } }

Other than the method showing up in Intellisense for the type, extension methods hadn't added anything. I was sure there must be something more. Maybe the compiler was doing something under the hood? So I compiled the following code and opened the resulting executable in ILDasm. (The non-extension method has been renamed to VowelCount to differentiate it from VowelCountEx.)


    static void Main(string[] args)
    {
        string value = "my string";
        int count = value.VowelCountEx();
        count = ExtensionMethods.VowelCount(value);
    }

Here's the resulting IL:


    .method private hidebysig static void  Main(string[] args) cil managed
    {
      .entrypoint
      // Code size       22 (0x16)
      .maxstack  1
      .locals init ([0] string 'value',
               [1] int32 count)
      IL_0000:  nop
      IL_0001:  ldstr      "my string"
      IL_0006:  stloc.0
      IL_0007:  ldloc.0
      IL_0008:  call       int32 Test2.ExtensionMethods::VowelCountEx(string)
      IL_000d:  stloc.1
      IL_000e:  ldloc.0
      IL_000f:  call       int32 Test2.ExtensionMethods::VowelCount(string)
      IL_0014:  stloc.1
      IL_0015:  ret
    } // end of method Program::Main

So there really isn't any functional difference between extension methods and normal static methods.

If, then, extension methods are essentially syntactic sugar, should they be used? This comes back to one of the basic principles of clear communication: consistency. If you are going to use extension methods, use them everywhere; if you are going to use normal static methods, do that everywhere. But please, please, please don't mix the two. One of my pet peeves when trying to understand a new code base is inconsistency because it means that I constantly have to either look elsewhere in the code or in the documentation (if any) to discover how to use it. Mixing extension methods and static methods is certain to cause confusion.

The biggest advantage to extension methods is discoverability: when I type my variable name in an Intellisense-aware editor, the extension methods are added to the list. In contrast, when using a normal static method, I have to remember the name of the class that implements it in order to call it. Another plus is the ability to 'extend' sealed classes and valuetypes. I often find that BCL valuetypes don't have the conversions that I need. Now, I can add the conversion and have it display in Intellisense. A third is that they integrate seamlessly with generics. This is not an essential, but it sure comes in handy sometimes. Finally, my code will no longer be littered with calls to StringHelper.This() and ControlHelper.That().

There are also a couple of things I don't like. Adding the this modifier to the function signature is really confusing if you haven't seen it before. The first time I saw it, I thought it was a syntax error. Imagine my surprise when it compiled! However, instead of compiling the code, I could have simply 'fixed' the syntax error. Then when I compiled I would have seen a syntax error like this:

'Program' does not contain a definition for 'CountVowelsEx' and no extension method 'CountVowelsEx' accepting a first argument of type 'String' could be found (are you missing a using directive or an assembly reference?)

Hmmm...there's nothing wrong with the static method because I fixed the syntax error. Why won't this #$!$!#$#$ file compile? A second issue I have with extension methods is that they can pollute Intellisense--thus frustrating their biggest advantage. Since extension methods are inherited by all derived classes, deeply derived classes can end up with so many methods that it's difficult to find the one you're looking for. However, my biggest beef is that the differences between static and instance methods are no longer obvious in the calling function. Consider the following code:


    static void Main(string[] args)
    {
        string value = null;
        int count = value.Length;
        count = value. VowelCountEx();
    }

What happens when value.Length is called? The CLR runtime throws a NullReferenceException immediately: the get_Length function is never called because there is no object through which to reference it. However, when value.VowelCountEx() is called, the code jumps to the function and begins executing. The NullReferenceException isn't thrown until the enumerator for the object is accessed in the foreach statement. If you understand that VowelCountEx is actually a static method, this makes perfect sense; however, there is no way to tell this by examining the code in the calling function. This type of subtle difference causes maintenance developers to tear their hair out because the reason isn't obvious. (If you've ever spent time debugging a problem hidden in someone else's C/C++ macro, you know what I'm talking about.) A corollary to this is that I never need to add a null check for the calling object in an instance method because the object must be valid; however, I do have to add one to an extension method (if the extended object is a reference type) because there is no such guarantee.

So my answer is yes to both questions: extension methods are syntactic sugar but they can be useful syntactic sugar. For myself, I'm going to begin using extension methods because I like the discoverability and understand the potential pitfalls. However, I'm going to give myself this advice:

Use either extension methods or regular static methods to extend class functionality, but not both.
Be aware that a call to an extension method is a call to a static method, not an instance method.
Keep the code for extension methods in close proximity to the classes they extend so that I'm reminded to update them when I make changes to the original class. If you want to keep all extension methods in a single class but still achieve proximity, use partial classes.
Check for null objects in extension methods that operate on reference types.

If I've missed any pros or cons, please post a comment-discussion is good for the soul.

Cheers,
Dan

DISCLAIMER:
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer.

Hiding a non-virtual property for a derived control at design-time

2010-10-23T21:17:00Z

I've recently been developing a custom control (BarControl) that derived from an existing control (FooControl). There were two requirements related to the derived control's border style:

The BorderStyle property should not be modified at runtime
The BorderStyle property should not be displayed in the Properties pane at design-time

Since the base control exposed a BorderStyle property, I thought I'd need to do three things:

override the property
change it's access modifier to protected so that only derived classes can access it
add a [Browsable(false)] attribute to remove it from Visual Studio's Properties pane

So I blithely whipped out the following code:


    [Browsable(false)]
    protected override BorderStyle BorderStyle
    {
        get { return base.BorderStyle; }
        set { base.BorderStyle = value; }
    }

The compiler just as blithely hit me with the following error:


    Error 1  'BarControl.BorderStyle.get': cannot override inherited member 'FooControl.BorderStyle.get' because it is not marked virtual, abstract, or override
    Error 2  'BarControl.BorderStyle.set': cannot override inherited member 'FooControl.BorderStyle.set' because it is not marked virtual, abstract, or override

Oops! I had expected the BorderStyle property to be virtual and it wasn't. The solution--like most solutions--was obvious once I found it: use the new, rather than the override, modifier to hide the base class property. So I quickly changed the code to:


    [Browsable(false)]
    protected new BorderStyle BorderStyle
    {
        get { return base.BorderStyle; }
        set { base.BorderStyle = value; }
    }

Now the compiler was happy, so everything would work as expected, right? I switched to my test app, drug an instance of my control onto a form, and looked for the BorderStyle property in the Properties pane. Lo and behold, it was still there. I was stumped. I had hidden the base property and marked the new property with [Browsable(false)]. What could be wrong?

It took a close reading of the documentation for the new modifier to find the problem: the new modifier overrides members with the same signature. Since the access modifier is part of a member's signature, changing the access modifier from protected to public meant I wasn't hiding the BorderStyle property in the base class. As a result, the BrowsableAttribute was applied to the BorderStyle property in the derived class but not the BorderStyle property in the base class.

What to do. I needed to hide the BorderStyle property at design time, so I needed to make it public in the derived class; however, I also needed to hide the property at runtime so I needed to make it protected. Perhaps, I could apply the protected access modifier to the property's getter and setter methods while still leaving the property access modifier as public. So I tried this:


    [Browsable(false)]
    public new BorderStyle BorderStyle
    {
        protected get { return base.BorderStyle; }
        protected set { base.BorderStyle = value; }
    }

The compiler didn't like it:


    Error 1  Cannot specify accessibility modifiers for both accessors of the property or indexer 'BarControl.BorderStyle'

Since the goal was to keep the property from being modified at runtime, I settled on the following solution:


    [Browsable(false)]
    public new BorderStyle BorderStyle
    {
        get { return base.BorderStyle; }
        protected set { base.BorderStyle = value; }
    }

I'm not sure that there isn't a better solution, but this meets the criteria:

The BorderStyle property is not displayed in the Properties pane at design-time
The BorderStyle property cannot be modified at runtime

So the three things I actually needed to do were

hide the property in the base class with the new modifier
change the access modifier of the property's setter method to protected so that only derived classes can access it
add a [Browsable(false)] attribute to the derived class property to remove it from Visual Studio's Properties pane

I hope you find this helpful.

Cheers
Dan

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

Back in Business

2010-10-23T19:12:00Z

After a hiatus of 3+ years, I've decided to reopen blue collar. The focus will no longer be the .Net Compact Framework, but will still be aimed at providing information and solutions that will save time and effort for developers delivering solid code on a daily basis. If you find these articles useful, please let me know; if you find that the explanations aren't clear or that information is missing, please let me know that as well.

Cheers,
Dan

Adding Compact Framework Design-Time Attributes, or More Fun With TextBoxes

2007-02-08T22:41:00Z

A common user-interface feature is to select the contents of a text-box when the textbox gets focus. The CF textbox control doesn't do this by default but it's not difficult to add with managed code. While I'm at it, I'll add a SelectTextOnFocus property to the textbox's property window so the developer can determine at design-time whether or not to use this functionality.

The code is trivial: I simply override the OnGotFocus() method and add a call to SelectAll(). However, there is one interesting point: the call to SelectAll() must come after the call to the base class's OnGotFocus() method. Otherwise, the base class will undo the selection.


    public class DerivedTextBox : TextBox
    {
        protected override void OnGotFocus(EventArgs e)
        {
            base.OnGotFocus(e);
            this.SelectAll();
        }
    }

Adding the SelectAllOnFocus property is trivial as well.


    public class DerivedTextBox : TextBox
    {
        protected override void OnGotFocus(EventArgs e)
        {
            base.OnGotFocus(e);
            if (this.selectAllOnFocus)
            {
                this.SelectAll();
            }
        }

        private bool selectAllOnFocus = false;
        public bool SelectAllOnFocus
        {
            get { return this.selectAllOnFocus; }
            set { this.selectAllOnFocus = value; }
        }
    }

Unfortunately, adding design-time properties for the Compact Framework is not. (I could devote an entire article to the things I dislike about the Compact Framework designer support, probably entitled Compact Should NOT Mean More Difficult).

In the full .NET framework, design-time behavior is added by decorating properties with design-time attributes. For instance, to make the property appear in the Properties window, the Browsable attribute is added to the property like this:


        [Browsable(true)]
        public bool SelectAllOnFocus
        {
            get { return this.selectAllOnFocus; }
            set { this.selectAllOnFocus = value; }
        }

I like this because it keeps everything I need to know about a property in a single place. However, the classes that support the design-time attributes were removed from the Compact Framework because design-time work is not done on devices. As a result, the code above would no longer compile. This meant that an alternate method was needed for specifying design-time attributes for device applications. The solution chosen was to put the attributes in...drum roll, please...a separate XML file. And, naturally, a new XML file means a new schema (XMTA). For purposes of this article, I will use the term 'XMTA file' to refer to this type of file.

There are two ways that I know of to create an XMTA file. The first is described in Walkthrough: Adding a Simple Attribute to a User Control. Since there is no documentation (other than %vsinstalldir%\Xml\Schemas\xmta.xsd) describing the schema, this was how I created my first XMTA file. The second method is to edit the XMTA file directly in the Visual Studio editor. I prefer this method because Intellisense can give some guidance as to what tags are valid. To do this, I

create an XML file with a .xmta extension

add the following boiler-plate code:


    <?xml version="1.0" encoding="utf-16"?>
    <Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd">
      <Class Name="MyNamespace.MyClass">
        <Property Name="MyProperty">
          <!-- TODO: enter attributes -->
        </Property>
      </Class>
    </Classes>

change the Class and Property names to match those in my project
type an open bracket (<) under the TODO comment and Intellisense will display a list of attributes that can be applied to the property.

After adding the Browsable attribute to my SelectAllOnFocus property, the XMTA file looks like this:


    <?xml version="1.0" encoding="utf-16"?>
    <Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd">
      <Class Name="DeviceApplication1.DerivedTextBox">
        <Property Name="SelectAllOnFocus">
          <Browsable>true</Browsable>
        </Property>
      </Class>
    </Classes>

After I compile my project, return to the design window, and drag a new DerivedTextBox object onto my form, I should see the SelectAllOnFocus property in the control's property window.

If I view the properties in categories, I'll see that SelectAllOnFocus is listed in the Misc category. It would be nice to have it show up in the Behavior category. This is done by adding a Category attribute to the property in the XMTA file.


        <Property Name="SelectAllOnFocus">
          <Browsable>true</Browsable>

          <Category>Behavior</Category>

        </Property>

Adding a Description attribute will cause descriptive text to be displayed below the Properties list.


        <Property Name="SelectAllOnFocus">
          <Browsable>true</Browsable>
          <Category>Behavior</Category>

          <Description>Determines whether the contents of the control should be selected when focus is moved to the control.</Description>

        </Property>

Finally, the default value for the property can be specified by adding a DefaultValue attribute. This attribute requires that the value and its type be specified by inner tags:


        <Property Name="SelectAllOnFocus">
          <Browsable>true</Browsable>
          <Category>Behavior</Category>
          <Description>Determines whether the contents of the control should be selected when focus is moved to the control.</Description>

          <DefaultValue>
            <Type>bool</Type>
            <Value>false</Value>
          </DefaultValue>

        </Property>

Though the process of adding my property to the Properties list was more convoluted than I'd like, I can now set the value of the SelectAllOnFocus property at design time and Visual Studio will generate code like this to initialize it.


        private void InitializeComponent()
        {
          ...
            this.derivedTextBox1 = new DeviceApplication1.DerivedTextBox();
          ...
            // 
            // derivedTextBox1
            // 
            this.derivedTextBox1.Location = new System.Drawing.Point(33, 109);
            this.derivedTextBox1.Name = "derivedTextBox1";

            this.derivedTextBox1.SelectAllOnFocus = false;

            this.derivedTextBox1.Size = new System.Drawing.Size(100, 21);
            this.derivedTextBox1.TabIndex = 1;
            this.derivedTextBox1.Text = "derivedTextBox1";
          ...
            this.Controls.Add(this.derivedTextBox1);
          ...
        }

I hope this takes a little of the mystery out of adding design-time support to Compact Framework controls.

Cheers
Dan

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

Setting Alignment in TextBoxes...No Looking Glass Required

2007-02-08T02:52:00Z

In yesterday's post I stated that "non-character keys do not trigger KeyPress events." While that is perfectly true, I misunderstood what was meant by a non-character key. In the non-managed Win32 world, pressing a key generates a WM_KEYDOWN, one or more WM_CHAR messages, and a WM_KEYUP message. The managed KeyPress event corresponds to the WM_CHAR message. Windows generates WM_CHAR messages for keys that are mapped to ASCII characters by the keyboard driver. Since pressing the Enter key generates an ASCII character code (0xA, 0xD, or both), a KeyPress event is generated for it.

So, while the code I posted yesterday works, it can be simplified by eating the Enter key in the textbox's KeyPress event handler rather than using the form's KeyPreview.


        private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
        {
            if ('\r' == e.KeyChar)
            {
                // Supress enter key
                e.Handled = true;
            }
        }

In addition, since the textbox is no longer dependent on the form for functionality, I can package it up in it's own class.


    public class TextBoxWithAlignment : TextBox
    {
        // Remember whether user wants the textbox to act like a 
        // single-line or multiline textbox.
        //
        private bool multiline = false;

        public TextBoxWithAlignment()
        {
            // The underlying control will always be a multiline textbox
            //
            base.Multiline = true;
        }

        protected override void OnKeyPress(KeyPressEventArgs e)
        {
            // When the user wants a single-line textbox,
            // eat carriage returns
            //
            if (!this.multiline && '\r' == e.KeyChar)
            {
                e.Handled = true;
            }
            base.OnKeyPress(e);
        }

        // Override the Multiline property to use the internal multiline flag
        //
        public override bool Multiline
        {
            get
            {
                return this.multiline;
            }
            set
            {
                this.multiline = value;
            }
        }
    }

Pretty nifty, IMHO.

Cheers
Dan