The ColorPicker WinForms Control

Developing a simple ColorPicker WinForms control by implementing the IWindowsFormsEditorService interface and leveraging the WinForms design-time infrastructure.

Of course, there is the standard ColorDialog component, but the drop-down color selector is more user-friendly, IMHO. (Should I say cool?)

• The control should look and act like a button.
• The button should be colored with the currently selected color and, optionally, it should display the currently selected color's name.
• Clicking the button should drop-down the built-in WinForms color selector and the control should change its appearance to a "pushed down" look.

The following is the important part of the ColorPicker's public contract (the semantics should be self-explanatory):

Namespace LaMarvin.Windows.Forms

Public Class ColorPicker
  Inherits Control
  Public Event ColorChanged As EventHandler
  Public Property Color() As Color

But wait!

If you want to learn something about the inner workings of the WinForms design-time support, as well as some undocumented .NET framework tricks, please, read on.

For more information about the PropertyGrid control and its use of attributes, see the Shawn Burke's article at MSDN.

Namespace System.Drawing

<EditorAttribute("System.Drawing.Design.ColorEditor"), _
  GetType(System.Drawing.Design.UITypeEditor))> _
Public Structure Color

Nevertheless, with some help of ILDASM and the Lutz Roeder's .NET Reflector, I was able to find out how a ColorEditor instance is hosted within the PropertyGrid. Moreover, I was also able to emulate the hosting within the ColorPicker control, which is the focus of the remainder of this article.

To better understand the process of hosting the ColorEditor, let's quickly recap how the PropertyGrid control uses the EditorAttribute when editing properties of a given object:

When a row within the PropertyGrid gets focus, the grid looks first at the property itself, then at the property's type in order to see, if there is an EditorAttribute applied to one of them. The EditorAttribute specifies the System.Type that should be used as the editor for the given property.

In theory, a type can have more than one editor. However, currently only one 'type' of editors are supported - the ones that derive (directly or indirectly) from the System.Drawing.Design.UITypeEditor class.)

Namespace System.Drawing.Design

Public Class UITypeEditor

Public Overridable Function GetEditStyle( _
  ByVal context As ITypeDescriptorContext _
) As UITypeEditorEditStyle

When the user clicks the drop-down button, the PropertyGrid calls another overridden method - ColorEditor.EditValue:

Namespace System.Drawing.Design

Public Class UITypeEditor

Public Overridable Function EditValue( _
  ByVal context As ITypeDescriptorContext, _
  ByVal provider As IServiceProvider, _
  ByVal value As Object _
) As Object

• Queries the passed in IServiceProvider instance for an IWindowsFormEditorService implementation.
• Stores the IWindowsFormEditorService in a member variable.
• Creates an instance of a private ColorUI class, which implements the actual user interface and interacts with the user.
• Calls the IWindowsFormEditorService.DropDownControl method passing it the custom control instance.
• When the user selects a new color, the ColorEditor calls the IWindowsFormEditorService.CloseDropDown method, which (you guessed that) closes the drop-down UI and causes the IWindowsFormEditorService.DropDownControl method to return.

In fact, this implementation of UITypeEditor.EditValue method is common. If you've ever implemented your own drop-down UITypeEditor, it is highly likely that you've implemented it according to the above-described pattern.

Namespace System

Public Interface IServiceProvider
  Public Function GetService( _
    ByVal serviceType As Type) As Object
End Interface

...

Namespace System.Windows.Forms.Design

Public Interface IWindowsFormsEditorService
  Public Sub CloseDropDown()
  Public Sub DropDownControl(ByVal control As Control)
  Public Function ShowDialog( _
    ByVal dialog As Form) As DialogResult
End Interface

There were several other minor issues that I had to solve and I've described them in the ColorPicker.vb source file.

There was one issue, however, that I'd like to discuss here in more detail.

When the drop-down color selector is displayed by calling the IWindowsFormsEditorService.DropDownControl method, it is expected not to return only until after the user either selects a new color or she cancels the selection. The cancellation can be performed in a variety of ways: by pressing the Esc key, by clicking outside of the drop-down box, by pressing the Ctrl+Esc system key combination or by clicking the ColorPicker button once again.

In other words, the DropDownControl method implementation should block while dispatching windows messages caused by the user interaction with Windows (including the drop-down color selector).

Do you remember the old pal, DoEvents?

This time, however, it is exposed as the DoEvents method of the System.Windows.Forms.Application class. Calling the method causes processing of all the Windows messages in the current thread's message queue.

Here is a pseudocode for my first DropDownControl implementation, which uses the DoEvents method:

Namespace LaMarvin.Windows.Forms
...
Public Class ColorPicker
...
  Private Class EditorService
    Public Sub DropDownControl(ByVal control As Control) _
      Implements IWindowsFormsEditorService.DropDownControl
 
      ' Display the drop-down color selector, which
      ' is hosted within a _DropDownHolder Form instance.
    
      ' Wait until the drop-down is closed.
      Do While _DropDownHolder.Visible
        Application.DoEvents()
      Loop
		 ...
End Sub

It worked fine this way until I realized that when the drop-down color selector is displayed, the process hosting the ColorPicker control eats 100% of the CPU.

Too bad!

Once again, I've turned to the .NET Reflector tool in order to see how the DropDownControl method is implemented within the PropertyGrid itself (which, obviously, doesn't eat 100% CPU while displaying the color selector).

Here is what I found out:

Namespace System.Windows.Forms.PropertyGridInternal
  Private Class PropertyGridView
	  Private Class DropDownHolder
      Public Sub DoModalLoop()
        Do While MyBase.Visible
         Application.DoEvents
         UnsafeNativeMethods.MsgWaitForMultipleObjects( _
           1, 0, 1, 250, 255)
        Loop
      End Sub
...

DWORD MsgWaitForMultipleObjects(
  DWORD nCount,  // number of handles pointed to by the
     // pHandles argument
  const HANDLE* pHandles, // pointer to an array of object
     // handles whose signaled state is checked
  BOOL bWaitAll,  // all object handles should be
     // signaled (TRUE) or any one of them (FALSE)
  DWORD dwMilliseconds, // wait timeout
  DWORD dwWakeMask  // which input events (messages)
     // should cause the function to return (in addition
     // to signaling objects pointed to by pHandles)
);

The weird thing is that .NET framework calls the function with the number of object handles equal to ONE, while the pointer to the array of handles is ZERO (Nothing in VB nomenclature).

This way of calling the function is not documented (AFAIK). One can only guess that such a call is used to suspend the calling thread until a message has to be processed WITHOUT checking the signaled state of any object handle.

Nevertheless, because the call is used within WinForms implementation itself, I find it quite safe to use it within your own applications.

I've used it with ColorPicker and the problem with the drop-down form consuming 100% CPU cycles disappeared.

You can download the ColorPicker control project along with the accompanying demo project here.

The ColorPicker.vb source code is here.

Enjoy!

© Palo Mraz, Tuesday, October 21, 2003

PS: A follow-up article is available here (added Thursday, September 16, 2004).