Forms Designer

Custom Forms Designer: Toolbox and ToolboxService - Part 1

Mark Treadwell — Fri, 26 Oct 2007 04:41:24 GMT

Reminder: All posts in this series can be found here.

The Toolbox and the DesignSurface work together to allow a developer to add new components and controls to the design surface. There are two interfaces that implement this functionality: IToolboxService and IToolboxUser.

IToolboxService defines an interface that provides methods and properties to manage and query the Toolbox capabilities in a development environment. All forms designer systems must implement the IToolboxService in their Toolbox in order to provide the expected Windows Forms UI functionality. This service is added to the ServiceContainer and can be accessed at any time. There are 15 methods and two properties in the interface which I will not cover here in detail. Many of those methods deal with adding, deleting and selecting Toolbox items.

IToolboxUser defines an interface for setting the currently selected toolbox item and indicating whether a designer supports a particular toolbox item. A forms designer will implement an IToolboxUser interface that consists of only two methods: GetToolSupported and ToolPicked. You use GetToolSupported to filter the items that can be added onto the designer.

Implementation: There are several steps you have to take to build a Toolbox for a Forms Designer system.

Create a user interface that displays the tools to the user. This is typically implemented as a classic TreeView, or as sliding tree control that behaves much like Windows Explorer, but without grid or connection lines. Building the desired functionality can take quite a bit of time. There is a nice Code Project article that has a mostly-complete solution with multi-level tabs. There are several design decisions you will have to make before you start coding. Besides the visual representation already noted, you must decide how you will discover, categorize, and load the tools. One of the MSDN Magazine articles describes three methods: hard coding (not recommended), configuration file, and attribute decorated classes loaded from a known location and checked using reflection.
Implement the IToolboxService. The three main members of this interface are GetSelectedToolboxItem, SerializeToolboxItem, and DeserializeToolboxItem. Other useful members include GetCursor, IsSupported, IsToolboxItem, and SelectedToolboxItemUsed.
Plug the IToolboxService implementation into the design-time environment.
Create a keyboard interface.
Handle Toolbox events, such as tool selection, keyboard, mouse clicks and drag and drop.

Usage: There are four ways a developer can add a component or control to a forms designer DesignSurface; one uses the keyboard, while the other three use the mouse. The Visual Studio Toolbox functions are described here. I will talk about the changes required to the sample application to implement the Visual Studio functionality in Part 2 of this post.

Keyboard: The Visual Studio Toolbox keyboard interface is described here. Essentially, you Ctrl+Tab/cursor to the Toolbox (or press Ctrl+Alt+X), cursor to the desired control and hit Enter. The control will be added to the DesignSurface. Ctrl+Up Arrow, Ctrl+Down Arrow, Left Arrow, and Right Arrow also have control functions within the Toolbox.
Mouse: Double-Click a Toolbox icon. The control will be added to the DesignSurface. This has the same effect as using the keyboard method.
Mouse: Single Click a Toolbox icon. Move the cursor over the DesignSurface, were it will turn to a Crosshair ready for you to click and drag the desired control location and size. Visual Studio customizes the Crosshair cursor with color overlay of the selected tool icon until the mouse has been clicked and released. This operation can be canceled with the Esc key.
Mouse: Drag and Drop a Toolbox icon. Click a control icon, drag it onto the DesignSurface, and drop it where you want it. This operation can be canceled with the Esc key.

To allow the icons from the Toolbox to be added to the DesignSurface using the mouse or keyboard, the Toolbox in the sample code hooks onto the KeyDown and MouseDown events. IToolboxUser.ToolPicked is called for the Enter key or a mouse double-click. The sample code shows how to serialize the ToolboxItem into a DataObject and to DoDragDrop for when a mouse single-click event occurs. IToolboxService.SerializeToolboxItem will be called on mouse up and the item will be added to the designer.

When a new control or component is added to the DesignSurface from the Toolbox, the NameCreationService is used to give it a unique name. My discussion of this service and my modifications to the sample code are described here.

Custom Forms Designer: ServiceContainer

Mark Treadwell — Tue, 23 Oct 2007 03:15:32 GMT

Reminder: All posts in this series can be found here.

Simply, it is a container for services. Services are classes that have a well-known interface, that have instantiations which be stored in service containers, can be obtained from a service provider, and are addressable by type. The ServiceContainer class is a service provider and implements IServiceProvider. You obtain a service by supplying the Type of the service you want to the service provider's GetService method. The ServiceContainer.GetService method is declared like this.

public virtual Object GetService(Type serviceType);

This is how you obtain a a reference to a service in a class derived from DesignSurfaceManager or DesignSurface. The cast is required because GetService returns an Object.

INameCreationService serviceNameCreation = (INameCreationService)(this.GetService(typeof(INameCreationService)));

Both DesignSurfaceManager and DesignSurface implement ServiceContainer. This may appear to lead to confusion, but you do not have to keep track of which container holds what service. One of the nice features of using the DesignSurfaceManager class is that it automatically merges services between it and the DesignSurfaces.

There is no documentation of how to use these multiple implementations, but it makes sense to put general, non-DesignSurface services such as IHelpService, IDesignerEventService, and INameCreationService in the central DesignSurfaceManager ServiceContainer. DesignSurface-specific services such as ISelectionService would logically be with each DesignSurface.ServiceContainer.

MSDN states the following about the DesignSurfaceManager.ServiceContainer Property: The DesignSurfaceManager class provides several design-time services automatically. You can override each of these services by replacing them in the protected ServiceContainer property. To replace a service, override the constructor, call base, and make any changes through the protected ServiceContainer property. All services added to the service container that implement the IDisposable interface are disposed when the design surface manager is disposed. The DesignSurfaceManager class provides the IDesignerEventService interface as the default service. IDesignerEventService provides a global eventing mechanism for designer events. With this mechanism, an application is informed when a designer becomes active. The service provides a collection of designers and a single place where global objects, such as the Properties window, can monitor selection change events.

What is interesting here is that MSDN itself does not state what the default design-time services are. A MSDN Magazine designer hosting article provides a table of the default DesignSurface design-time services. An important part of that table is listing which services are not replaceable due to their interrelationships. I wrote some code to see what services were running in the two containers for the sample application and found the following.

HostSurfaceManager.ServiceContainer Services
--------------------------------------------
IDesignerEventService
INameCreationService
IToolboxService

HostSurface.ServiceContainer Services
--------------------------------------------
IComponentChangeService
IDesignerEventService
IDesignerHost
IExtenderListService
IExtenderProviderService
IInheritanceService
IMenuCommandService
INameCreationService
IReferenceService
ISelectionService
IToolboxService
ITypeDescriptorFilterService

This list matches almost perfectly with the default design-time service table noted above. It was not surprising to see the three HostSurfaceManager services were also visible from the HostSurface because the System.ComponentModel.Design.DesignSurfaceManager has a small bit of code in its MergedServiceProvider GetService method that looks like the following:

Object service = this._primaryProvider.GetService(serviceType);
if (service == null)
{
  service = this._secondaryProvider.GetService(serviceType);
}
return service;

The primary provider for the HostSurface is its own ServiceContainer. The secondary provider for the HostSurface is the HostSurfaceManager.ServiceContainer. As shown in the code snippet, any HostSurface service is preferred over an identical one in the HostSurfaceManager. Any service unavailable in the HostSurface but present in the HostSurfaceManager is accessible as well.

Custom Forms Designer: Name Creation Service

Mark Treadwell — Thu, 18 Oct 2007 23:12:15 GMT

Reminder: All posts in this series can be found here.

The first code I will look at is from one of the simplest services supporting the Windows Forms designer. The Name Creation Service is called each time you drop a control/component onto the visual design surface. Your job is to return a unique name for the new control that also means something.

The standard process, per convention, is to take the control/component Type name, camel case it (lower case the first letter) since it will be a member variable, and then append a digit suffix to make it unique from all other controls/components on the form. The number ensures it remains unique for languages which are not case sensitive.

The sample code implements only the INameCreationService.CreateName method. I modeled my implementation off of the sample code for INameCreationService here. I found the sample CreateName code to be excessively complex:

    string INameCreationService.CreateName(IContainer container, Type type)
    {
      ComponentCollection cc = container.Components;
      int min = Int32.MaxValue;
      int max = Int32.MinValue;
      int count = 0;
      for (int i = 0; i < cc.Count; i++)
      {
        Component comp = cc[i] as Component;
        if (comp.GetType() == type)
        {
          count++;
          string name = comp.Site.Name;
          if (name.StartsWith(type.Name))
          {
            try
            {
              int value = Int32.Parse(name.Substring(type.Name.Length));
              if (value < min)
                min = value;
              if (value > max)
                max = value;
            }
            catch (Exception ex)
            {
              Trace.WriteLine(ex.ToString());
            }
          }
        }
      }
      if (count == 0)
        return type.Name + "1";
      else if (min > 1)
      {
        int j = min - 1;
        return type.Name + j.ToString();
      }
      else
      {
        int j = max + 1;
        return type.Name + j.ToString();
      }
    }

My implementation is simpler:

    String INameCreationService.CreateName(IContainer container, Type dataType)
    {
      if (dataType == null)
      {
        throw new ArgumentNullException("dataType");
      }
      // The base component name is the Type name with the first character lower case
      String name = Char.ToLower(dataType.Name[0]) + dataType.Name.Substring(1);
      int number = 1;
      // If the container parameter is null, no container search is needed
      if (container != null)
      {
        // Increment counter until we find a name that is not in use
        while (container.Components[name + number.ToString()] != null)
        {
          ++number;
        }
      }
      return (name + number.ToString());
    }

I also added implementations of INameCreationService.IsValidName and INameCreationService.ValidateName. The IsValidName method returns a Boolean and does not throw any exceptions. The ValidateName method can throw an exception to return the exact reason why the candidate name fails. Generally, the code structure of the two methods should be similar, differing primarily in how they communicate an error back to the developer.

    bool INameCreationService.IsValidName(String name)
    {
      // Cannot be null or empty
      if (String.IsNullOrEmpty(name))
      {
        return false;
      }
      // Cannot start with a number
      UnicodeCategory uc = Char.GetUnicodeCategory(name, 0);
      if (uc == UnicodeCategory.DecimalDigitNumber)
      {
        return false;
      }
      // Cannot have anything other than letters and numbers
      foreach (Char c in name)
      {
        uc = Char.GetUnicodeCategory(c);
        switch (uc)
        {
          case UnicodeCategory.UppercaseLetter:
          case UnicodeCategory.LowercaseLetter:
          case UnicodeCategory.TitlecaseLetter:
          case UnicodeCategory.DecimalDigitNumber:
            break;
          default:
            return false;
        }
      }
      return true;
    }

    void INameCreationService.ValidateName(String name)
    {
      // Cannot be null
      if (name == null)
      {
        throw new ArgumentNullException("name");
      }
      // Cannot be empty
      if (name.Trim().Length == 0)
      {
        throw new ArgumentException("name cannot be of zero length");
      }
      // Cannot start with a number
      UnicodeCategory uc = Char.GetUnicodeCategory(name, 0);
      if (uc == UnicodeCategory.DecimalDigitNumber)
      {
        throw new ArgumentException("name cannot start with a number");
      }
      // Cannot have anything other than letters and numbers
      foreach (Char c in name)
      {
        uc = Char.GetUnicodeCategory(c);
        switch (uc)
        {
          case UnicodeCategory.UppercaseLetter:
          case UnicodeCategory.LowercaseLetter:
          case UnicodeCategory.TitlecaseLetter:
          case UnicodeCategory.DecimalDigitNumber:
            break;
          default:
            throw new ArgumentException("name must contain only letters and numbers");
        }
      }
      return;
    }

While there is a little more refactoring possible, that will be good enough for now.

Custom Forms Designer: A Restart

Mark Treadwell — Thu, 18 Oct 2007 02:02:32 GMT

Reminder: All posts in this series can be found here.

Some time ago, I started work on hosting the Windows Forms design surface in a project. Since that was nearly three years ago, I believe it was in the early .NET 2.0 days. My priorities got redirected and the project languished. A new project is clearly targeted at achieving the same goal, so I am back to building a solid implementation to get a beta front end out the door.

Those old posts are still of good use to remind me of everything I have forgotten in the interim:

Microsoft has subsequently posted a much more complete MSDN Magazine sample:

The Perfect Host: Create And Host Custom Designers With The .NET Framework 2.0 (download code)

I am using this sample as the basis for a new project which has a Windows Forms design surface at its heart. The main application will control the execution of a suite of 30 or so training applications in a standalone network. The instructor will be able to control everything from a central computer, remote boot the computers, group the computers together into teams/rooms, remote start individual applications on the computers, assign the teams to specific training exercises, monitor the status of the exercises, and remote stop the applications, and remote shut down the computers.

The use of the Windows Forms design surface will allow me to use custom Windows controls to represent the computers, groups, and rooms. This removes a significant amount of the complexity from the application. The tradeoff is the implementation of the Windows Forms design surface details are nontrivial, but not too difficult.

The first thing I did with the sample was to customize the code to my layout tastes (Ctrl+E, D), deleting and adding blank lines as I scanned through the files. Recompile. Change the namespaces to fit our development scheme. Recompile after each. Extract extra types where there was more than one in a file, again to match our standards. Recompile. Change the executable names and compile locations. Recompile. Add our assembly attributes. Recompile. Clean up the using statements at the top of the code files. Recompile.

OK. Now I feel like I can do some coding.

Custom Forms Designer: Framework 2.0

Mark Treadwell — Wed, 12 Jan 2005 02:10:00 GMT

In a comment to an earlier post, Tim Dawson pointed out that there are some significant improvements with respect to design surfaces in the upcoming .NET Framework 2.0. I was going to get to that after I covered what bits need to be assembled in order to get a design surface to work. Instead, I will modify my table now to indicate what the new Framework brings. Here is some info from MSDN2:

----------

The new DesignSurface class implements what the user perceives as a designer. DesignSurface is the user interface the user manipulates to change design-time features. DesignSurface provides a completely self-contained design surface.

The DesignSurface class may be used as a stand-alone designer, or it may be coupled with DesignSurfaceManager to provide a common implementation for an application that hosts multiple DesignSurface objects.

The DesignSurface class can be used by itself, or the user can derive a new class from it and augment the behavior.

The DesignSurface class provides several design-time services automatically. The DesignSurface class adds all of its services in its constructor. Most of these services can be overridden by replacing them in the protected ServiceContainer property. To replace a service, override the constructor, call base, and make any changes through the protected ServiceContainer property. All services added to the service container that implement IDisposable are disposed when the design surface is disposed.

The DesignSurface class also provides a single service that is available through a component's site. This service is unique for each component. In addition to ISite, the site also implements IDictionaryService interface. Check for the existence of this or other interfaces, rather than use indiscriminate casting, because other site implementations may not implement them.

----------

The codes for the following tables are as follows:

DH - Interface is implemented in the DesignerHost class
SF - Interface/class is implemented in a separate file
NI - Interface is not implemented, but commented stubs do exist
DEF - Uses the default implementation of the service
DR - DesignSurface class provides a default service that is replaceable
DN - DesignSurface class provides a default service that is not replaceable

Here are the classes and non-service interfaces.

Classes/Interfaces            |MSKB|MSDN|Dawson|2.0| Namespace
DesignerAttributeService      | -- | -- | -- |DR | System.ComponentModel.Design
DesignerLoader                | SF |    |      |   | System.ComponentModel.Design.Serialization
DesignerTransaction           | SF | SF | SF |DN | System.ComponentModel.Design
DesignSurface                 | -- | -- | -- |DR | System.ComponentModel.Design
IContainer                    | DH | DH | DH |   | System.ComponentModel
IComponent                    |    |    |      |   | System.ComponentModel
IDesigner                     |    |    |      |   | System.ComponentModel.Design
IDesignerFilter               |    |    |      |   | System.ComponentModel.Design
IDesignerHost                 | DH | DH | DH |DN | System.ComponentModel.Design
IDesignerLoaderHost           | DH |    |      |   | System.ComponentModel.Design.Serialization
IDisposable                   | DH | DH |      |   | System
IExtenderProvider             | SF |    | DH |   | System.ComponentModel
IRootDesigner                 | SF |    |      |   | System.ComponentModel.Design
ISite                         | SF | SF | SF  |   | System.ComponentModel

This table shows just the service interfaces that are/can be implemented.

Service Interfaces            |MSKB|MSDN|Dawson|2.0| Namespace
IComponentChangeService       | DH | DH | DH |DN | System.ComponentModel.Design
IDesignerEventService         | DH | DH |      |   | System.ComponentModel.Design
IDesignerOptionService        |    |    |      |   | System.ComponentModel.Design
IDesignerLoaderService        |    |    |     |   | System.ComponentModel.Design.Serialization
IDesignerSerializationManager | SF |    |    |   | System.ComponentModel.Design.Serialization
IDesignerSerializationProvider|    |    |      |   | System.ComponentModel.Design.Serialization
IDesignerSerializationService |    |    |     |   | System.ComponentModel.Design.Serialization
IDictionaryService            | SF | SF | SF  |DN | System.ComponentModel.Design
IEventBindingService          | SF |    |      |   | System.ComponentModel.Design
IExtenderListService          |    |    | DH |DR | System.ComponentModel.Design
IExtenderProviderService      | DH | DH | DH |DR | System.ComponentModel.Design
IHelpService                  | NI |    |     |   | System.ComponentModel.Design
IMenuCommandService           | SF | SF | SF |   | System.ComponentModel.Design
IMenuEditorService            | NI |    |     |   | System.Windows.Forms.Design
INameCreationService          | DEF| SF | SF |   | System.ComponentModel.Design.Serialization
IPropertyValueUIService       | NI |    |    |   | System.Drawing.Design
IReferenceService             | NI |    |      |DR | System.ComponentModel.Design
IResourceService              | SF |    |     |   | System.ComponentModel.Design
ISelectionService             | SF | SF | SF |DR | System.ComponentModel.Design
IServiceContainer             | DH | DH | DH  |DN | System.ComponentModel.Design
IServiceProvider              | DH | DH | SF  |DN | System
IToolboxService               | SF | SF | SF |   | System.Drawing.Design
ITypeDescriptorFilterService | SF | SF | DH |DR | System.ComponentModel.Design
ITypeResolutionService        | SF |    |     |   | System.ComponentModel.Design
IUIService                    |    |    | SF |   | System.Windows.Forms.Design

Next: What do these default services and classses do in support of the new DesignSurface class?

Custom Forms Designer: Classes and Interfaces

Mark Treadwell — Fri, 07 Jan 2005 04:12:00 GMT

An obvious first question when building a designer is: Where do you start? Unfortunately, the answer is that you need to start everywhere. A custom Windows Forms designer requires multiple interlocked services that all need to run correctly from the beginning. Getting this web of classes up an running is not trivial. Luckily, we have three operating samples at which to look.

I will start this part of the discussion with a comparison of the classes and interfaces implemented in the three samples. For info, I am including the namespace as well. Here are two tables of the classes and interfaces that can/are implemented in the samples. The table codes are as follows:

DH – Interface is implemented in the DesignerHost class
SF – Interface/class is implemented in a separate file
NI – Interface is not implemented, but commented stubs do exist
DEF – Uses the default implementation of the service

Here are the classes and non-service interfaces.

Classes/Interfaces             | MSKB | MSDN | Dawson|
DesignerLoader                 | SF |      |       | System.ComponentModel.Design.Serialization
DesignerTransaction            | SF | SF | SF   | System.ComponentModel.Design
IContainer                     | DH | DH | DH   | System.ComponentModel
IComponent                     |      |      |       | System.ComponentModel
IDesigner                      |      |      |       | System.ComponentModel.Design
IDesignerFilter                |      |      |       | System.ComponentModel.Design
IDesignerHost                  | DH | DH | DH   | System.ComponentModel.Design
IDesignerLoaderHost            | DH |      |       | System.ComponentModel.Design.Serialization
IDisposable                    | DH*1| DH*1|       | System
IExtenderProvider              | SF |      | DH   | System.ComponentModel
IRootDesigner                  | SF |      |       | System.ComponentModel.Design
ISite                          | SF*4| SF*3| SF*2 | System.ComponentModel

This table shows just the service interfaces that are/can be implemented.

Service Interfaces             | MSKB | MSDN | Dawson|
IComponentChangeService        | DH | DH | DH   | System.ComponentModel.Design
IDesignerEventService          | DH | DH |       | System.ComponentModel.Design
IDesignerOptionService         |      |      |       | System.ComponentModel.Design
IDesignerLoaderService         |      |      |       | System.ComponentModel.Design.Serialization
IDesignerSerializationManager | SF |      |       | System.ComponentModel.Design.Serialization
IDesignerSerializationProvider |      |      |       | System.ComponentModel.Design.Serialization
IDesignerSerializationService |      |      |       | System.ComponentModel.Design.Serialization
IDictionaryService             | SF*4| SF*3| SF*2 | System.ComponentModel.Design
IEventBindingService           | SF |      |       | System.ComponentModel.Design
IExtenderListService           |      |      | DH   | System.ComponentModel.Design
IExtenderProviderService       | DH | DH | DH   | System.ComponentModel.Design
IHelpService                   | NI |      |       | System.ComponentModel.Design
IMenuCommandService            | SF | SF | SF   | System.ComponentModel.Design
IMenuEditorService             | NI |      |       | System.Windows.Forms.Design
INameCreationService           | DEF | SF | SF   | System.ComponentModel.Design.Serialization
IPropertyValueUIService        | NI |      |       | System.Drawing.Design
IReferenceService              | NI |      |       | System.ComponentModel.Design
IResourceService               | SF |      |       | System.ComponentModel.Design
ISelectionService              | SF | SF | SF   | System.ComponentModel.Design
IServiceContainer              | DH*1| DH | DH*1 | System.ComponentModel.Design
IServiceProvider               | DH*1| DH*1| SF*2 | System
IToolboxService                | SF | SF | SF   | System.Drawing.Design
ITypeDescriptorFilterService   | SF | SF | DH   | System.ComponentModel.Design
ITypeResolutionService         | SF |      |       | System.ComponentModel.Design
IUIService                     |      |      | SF   | System.Windows.Forms.Design

*1 - Omitted from the class definition
*2 – Implemented in DesignSite.cs
*3 - Implemented in SiteImpl.cs
*4 - Implemented in SampleDesignSite.cs

What does this table show? Clearly, the MSKB sample is more comprehensive than the others. Also, the samples generally implement things in the same areas of their source code. There are some exceptions. My personal preference is to separate things out as much as possible. I intend to try to do that as I create my designer.

A Site must implement IDictionaryService and it may implement other interfaces. Interfaces/classes implemented in all three samples are highlighted in red. Some interfaces which are implemented but not included in the class definition are noted.

The .NET Framework SDK definition of IDesignerHost states that an implementation should include support for IServiceContainer and IServiceProvider. We can see that all three implement IServiceContainer in their DesignerHost class. Interestingly, Divil implements IServiceProvider in a separate file. I'll eventually take a look at the how and why of that.

The list above includes more than the material implemented in the samples. This of it as a revision of my initial list. As I get my hands around forms designers, I’ll likely update the tables.

Custom Forms Designer: The Goal

Mark Treadwell — Fri, 07 Jan 2005 03:29:00 GMT

My previous post on a .NET custom forms designer was a basic listing of the samples that are out there and some of their merits. It was not an exceptionally enlightened piece, so I intend to correct a few things and add some additional detail over the next couple of weeks. I included a listing of interfaces and made an unfulfilled hint at completing a full-featured design surface. I’ll get to the point eventually, so bear with me on this. We are off on a voyage of discovery....

I listed five examples of design surfaces in that first post. I will be throwing out two of them from consideration, but for different reasons. The first to be tossed is the MSDN GDI+ sample. This does not interact with the core .NET designer and is actually a poor substitute at trying to emulate it. It is OK for what it tries to do, but it does not fit my ultimate goal, which I’ll get to shortly.

The second example to be tossed is SharpDevelop. I am not trying to recreate Visual Studio as they are. SharpDevelop also has what can only be called an intricate extensible structure of "codons". Their extensibility structure seems to have created lots of additional work with little perceivable benefit. Perhaps I’m wrong. Anyway, you are welcome to look at their work, but the GPL restrictions were enough to turn me off.

That leaves us with three samples. For ease of reference, I’ll shorten their names as follows:

Dawson - DivElements, Hosting Windows Forms Designers (June 2003)
MSKB - Microsoft Knowledgebase, INFO: Code Sample That Demonstrates How to Create a Custom Form Designer by Using Visual C# .NET (August 2004)
MSDN - MSDN Magazine, .NET Internals: Tailor Your Application by Building a Custom Forms Designer with .NET (December 2004)

From these three samples, I intend to work towards a Windows Forms design surface that I will be able to then customize for my specific application. Therefore my goal is a rich design environment that will permit my users to create custom forms. Eventually, I'll create some custom controls and restrict them to only using those, but that is far in the future. In the meantime, I need to create a designer.

I need to make a few corrections to my earlier comments.

The Dawson sample consists of code and a brief accompanying article. There is some depth to parts of the discussion, but it does not cover things in detail. Overall, it is great and was the first published effort I found. The presented sample is very rough, but it works. The toolbox is actually a Listbox with the names of the controls. There is simple functionality.

The MSDN sample is far ahead of the Dawson version. Interestingly, I wondered if they came from the same code base, since there were some amazing similarities I saw. The MSDN toolbox is a Treeview with drag-and-drop functionality. Tools and icons are loaded from those installed on the user’s machine with the framework. Functionality is much better.

The MSKB sample is actually the best of the three. There is no real accompanying article, but the code is well-commented. In fact, the code appears to have been excised from a larger, more-finished program. There are several stubs present for additional interface implementations. These may well be the remains of routines left after custom code was removed, but their retention is appreciated. Many of the comments look suspiciously like the remains of XML comments that have had their XML wrappers deleted. This sample has by far the best functionality. Keyboard and menu commands are included. Code display in both VB and C# is supported. The toolbox looks much like Visual Studio’s and supports both mouse and keyboard. Overall, it wins as the most complete example.