Edit Almost Anything�Part 1

Monday Oct 11th 2004 by Declan Brennan

Learn about controls to edit a wide range of data types and/or complex DataSets.


There is a range of controls available as standard for Windows Forms in VisualStudio .NET 2003. These include TextBox to edit strings, CheckBox to edit booleans, and even a DateTimePicker. However, there is a vast range of types available in .NET. Furthermore, new types are added all the time both by Microsoft and the development community. Only a fraction of these types will contain data that we would expect to access via a user interface. This leaves us with the significant problem of ensuring our controls are capable of handling such types.


This is a screen grab of the object editor from AgileStudio, which is capable of editing a large range of data types in DataSets that may include a complex set of related tables. As a service to the community, Sekos is freely making available the source code for various controls used to accomplish this, all of which work with data binding. These include:

  • DataToolBar and DataButton, which support complex binding (to a table or list) for navigation purposes.
  • PropertyEditor for editing a large range of discrete types.
  • DataPicture to allow the editing of images.
  • A range of additional columns for use with DataGrid.
  • A GenericEditor tjat can automatically generate a UI appropriate to the tables in a DataSet.

We'll kick off the process in this article by examining the PropertyEditor and DataPicture controls used both standalone and within columns in a DataGrid.


How do we allow for the editing of a large range of discrete types, some of which may not even have been written yet? This seems like a tall order, but Microsoft has already put all the infrastructure in place for us with System.ComponentModel.TypeConverter and System.Drawing.Design.UITypeEditor. It's well documented how to go about creating a custom TypeConverter and/or UITypeEditor specific to a new data type using the TypeConverter and Editor attributes.

Among other things, this infrastructure is used by the PropertyGrid control to edit all the properties of a control at design time within Visual Studio. At runtime, it is unusual to want access to all the properties of a control. However, sometimes it might be desirable to allow the user to adjust individual properties; for example, to control the orientation of a 3D graph. (One way to handle this would be to have some kind of proxy object supporting ICustomTypeDescriptor to cut down the properties available to a PropertyGrid.) However, for maximum UI control, the best solution is to code a new control that implements IWindowsFormsEditorService. There are many aspects to supporting this service, including:

  • The painting of value glyphs; for example, a colour box sample for a Color editor
  • Providing a DropDown to pick from a set of Standard Values for enumerated types
  • Allowing custom dropDown controls or popup dialogs as appropriate

For the PropertyEditor to have the appropriate behaviour when editing a specific Value, it has a PropertyType property that specifies the Type of the Value. When configuring a PropertyEditor at design time, the user enters the name of a type that is converted to the actual type by using TypeTypeConverter.ConvertFrom():

public override object ConvertFrom(ITypeDescriptorContext context,
                                   culture, object value)
   if (value is string)
         typeResolver= (System.ComponentModel.Design.
      Type t= null;
      string typeName= (string)value;
      if (typeResolver!=null)
         t= typeResolver.GetType(typeName);
         // In the unlikely case that this property is bound to
         // another PropertyEditor so it can be changed at runtime,
         // ITypeResolutionService won't be available so we resort
         // to GetType instead.
         t= Type.GetType(typeName);
         // Hard Code System.Drawing in as an additional assembly
         // to search
         if (t==null)
            t= typeof(System.Drawing.Color).Assembly.
      return t;
   return base.ConvertFrom (context, culture, value);

As you can see, this uses ITypeResolutionService in the usual case where it is called at design time. Of course, this would not be available at runtime, in which case it resorts to Type.GetType(). One thing to watch out for is that unless you give this function a full assembly qualified type name, this method only searches in the calling assembly and in mscorlib.

The final property that I want to mention is UseStringAsUnderlyingType. This is not needed when binding to properties in other controls. However, it is needed when binding to a column in a DataSet where the data type is not one of the few that are currently supported by ADO.NET. In the case of an unsupported data type, the Value is stored as a string in the data type and is converted to and from this using TypeConverter.ConvertToInvariantString() and TypeConverter.ConvertFromInvariantString(). When displaying data in the control, TypeConverter.ConvertToString() is used instead to ensure that the data format is culture specific.

So, now that we've got a control that will edit any data type, we must be finished? Alas, it is never that simple. The default editor for an Image assumes we're going to embed the image in a resource file as opposed to, say, uploading it to a server. So, we'll handle this as a special case with our next control.


There is a built-in PictureBox control with an Image property. As it stands, it is strictly for setting images at application design time. DataPicture allows the setting of images at runtime. Unlike PictureBox, it is able to take the input focus and has a context menu to allow the transfer of images to and from the clipboard and from disk.

However, the biggest issue that needs to be overcome is the non-support of the Image data type in a DataSet. The most natural available data type is byte[], which appears as a base64binary in the DataSet schema. DataBinding, as standard, does not support conversion between byte[] and Image, but it can be enhanced by using event handlers. This is done as a two-stage process. First, an event handler is implemented to receive notifications when the DataBindings collection is changed. In this handler, individual handlers are attached to the Format and Parse events for the specific DataBinding for Image if it exists. This allows us to encapsulate all this messy conversion stuff inside the control instead of requiring event handlers in the application itself.

/// Construct a DataPicture
public DataPicture()
   // Register an interest in the DataBindings collection

// Check whether a Binding for Image has been added and if so
// attach event handlers to handle data conversion
private void DataBindings_CollectionChanged(object sender,
   CollectionChangeEventArgs e)
   Binding binding = this.DataBindings["Image"];
   if (binding!=null)
   { binding.Format+=new ConvertEventHandler(binding_Format);
     binding.Parse+=new ConvertEventHandler(binding_Parse);

// An event handler to handle the conversion from binary (byte[])
// to Image of data entering the control
private void binding_Format(object sender, ConvertEventArgs ev)
   if (!(ev.Value is Image) && ev.DesiredType==typeof(Image))
      byte[] img = ev.Value as byte[];
      ev.Value= sEmptyBitmap;
      if (img!=null && img.Length>0)
         System.IO.MemoryStream ms = new System.IO.MemoryStream();
            int offset = 0;
            ms.Write(img, offset, img.Length - offset);
            Bitmap bmp = new Bitmap(ms);
            ev.Value= bmp;
         catch (Exception)

// An event handler to handle the conversion from Image to binary
// (byte[]) of data leaving the control
private void binding_Parse(object sender, ConvertEventArgs ev)
   if ((ev.Value is Bitmap) && ev.DesiredType==
      { Bitmap bmp=
         System.IO.MemoryStream ms = new System.IO.MemoryStream();
         System.Drawing.Imaging.ImageFormat format= bmp.RawFormat;
         if (format==
            System.Drawing.Imaging.ImageFormat.MemoryBmp) format=
         ms.Close(); ev.Value=
   else if (ev.Value==null || ev.Value==sEmptyBitmap)

This mechanism is best used to handle reasonably small images. However, handling an image as just another part of the data does have the advantage of simplicity. There is no need to complicate the UI with upload image forms. The image will get saved with all the other data when the user presses the Save Button. This facilitates a transactional approach to data management.

Handling base64binary on the server—for example, using MS SQLServer—is fairly easy but beyond the scope of the current article. I'll just mention the handy "FOR BINARY BASE64" clause of the SELECT statement that is often used in conjunction with XML.

Enhancing DataGrid

Of course, it's all very well supporting simple binding. However, most real-world applications involve lists of data, making complex bound controls such as DataGrid essential. To implement a new type of column in a DataGrid, it is neccessary to derive a new class from DataGridColumnStyle. Consequently, DataGridPropertyEditorColumn is provided to support PropertyEditor and DataGridDataPictureColumn is provided to support DataPicture. How to do this is well covered in the MS documentation, so I won't go into it in detail here.

But briefly, to conserve resources, DataGrid does not create controls to populate every cell. Typically, each column will have one control that is used to interact with the user, when a cell in this column has the focus. Otherwise, a Paint() method is used to directly render the control onto a Graphics canvas. In cases like this, a call is made to a DrawData() method implemented in the appropriate control (PropertyEditor or DataPicture) to keep all rendering in one place. If all controls supported some interface with a method similar to this, a generic column would be possible in DataGrid; this would save a great deal of effort.

Points of Interest


The demo project at the start of this article includes a small MDI sample to demonstrate the editing of non-standard types with the following examples:

  • Editing properties of a control
  • Editingitems in a DataSet
  • Editing within a DataGrid

Reference style documentation for the library source is available here.

The code released with this article is based on a portion of the AgileStudio product, which extends Visual Studio. Check out the free evaluation at www.sekos.com, which automatically maintains the datasets and SQL StoreProcs required for a specific user interface (for Windows or Web applications).


In the next part of this series, I will discuss additional functionality for DataGrid. I will also examine data navigation and the automatic production of an intuitive user interface for a dataset with an arbitrarily complex set of tables and relations.

Please register your interest in the next part of this series by voting for this article.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved