 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
There are 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
are making freely 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.
DataGrid.
GenericEditor which 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:
In order for the PropertyEditor to have the appropriate behaviour
when editing a specific Value, it has a PropertyType
property which specifies the Type of the Value. When configuring a
PropertyEditor at design time, the user enters the name of a type
which is converted to the actual type using TypeTypeConverter.ConvertFrom():
public override object ConvertFrom(ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
{
if (value is string)
{
System.ComponentModel.Design.ITypeResolutionService typeResolver= (System.ComponentModel.Design.ITypeResolutionService)
context.GetService(typeof(System.ComponentModel.Design.ITypeResolutionService));
Type t= null;
string typeName= (string)value;
if (typeResolver!=null)
t= typeResolver.GetType(typeName);
else
{
// 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.GetType(typeName);
}
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 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
this.DataBindings.CollectionChanged+= new CollectionChangeEventHandler(DataBindings_CollectionChanged);
}
// 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();
try
{
int offset = 0;
ms.Write(img,offset, img.Length - offset);
Bitmap bmp = new Bitmap(ms);
ms.Close();
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==typeof(byte[]))
{
Bitmap bmp=(Bitmap)ev.Value;
System.IO.MemoryStream ms = new System.IO.MemoryStream();
System.Drawing.Imaging.ImageFormat format= bmp.RawFormat;
if (format==System.Drawing.Imaging.ImageFormat.MemoryBmp)
format= System.Drawing.Imaging.ImageFormat.Bmp;
bmp.Save(ms,format);
ms.Close();
ev.Value=(Byte[])ms.GetBuffer();
}
else if (ev.Value==null || ev.Value==sEmptyBitmap)
ev.Value=System.DBNull.Value;
}
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 which is often used in conjunction with XML.
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) in order 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
which would save a great deal of effort.
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:
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.