There are many good reasons to not use F# for your presentation layer, but doing so can be a great learning exercise. It's a bit cumbersome to set up, so I created a project template in order to simplify things.
When creating a WPF app in F# without this template, there are several hoops that you have to jump through:
Your new project gives you a nice, boring, empty form, but Visual Studio provides designer support when you open the XAML file. Event wire-up remains a manual process. Project templates can be created using File -> Export Template. A link to download the F# WPF Application template is at the end of this post.
Creating a new F# WPF Application project from the installed template gives you a Program.fs file:
open System
open System.IO
open System.Reflection
open System.Windows
open System.Windows.Controls
open System.Windows.Markup
open System.Xml
let xamlFile = Assembly.GetExecutingAssembly().GetManifestResourceStream("MainWindow.xaml");
let createWindow (xamlFile : Stream) =
using (XmlReader.Create(xamlFile))
(fun xaml -> XamlReader.Load(xaml) :?> Window)
[<STAThread>]
do
createWindow(xamlFile)
|> Application().Run
|> ignore
and a MainWindow.xaml file:
<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainForm" Height="300" Width="300"> <Grid> </Grid> </Window>
The template works with both Visual Studio 2008 and 2010, although in 2010 it pops up the following message. I haven't yet figured out how to prevent this, but choosing the Reload option gets things back on track.
The template is installed by placing the .zip file in your My Documents\Visual Studio 20xy\Templates\Project Templates folder.
C# identifiers may contain only alphanumeric and underscore characters. They may only begin with alphabetic or underscore characters. This apparently is a requirement of the language and not MSIL.
The code block below creates a dynamic class containing private variables spaced Property and spaced-out Property, along with thier respective public property wrappers Spaced Property and Spaced-out Property. Please refer to my previous post, Using the .Net PropertyGrid with dynamically-created types, Part 1: The Basics, for the details of the BuildProperty() method.
I can't attest to how much real-world value something like this might have, but it does illustrate some of .Net's inner workings.
protected object BuildDynamicClass()
{
// Define the dynamic assembly, module and type
AssemblyName assemblyName = new AssemblyName("DynamicAssembly");
AssemblyBuilder assemblyBuilder =
Thread.GetDomain().DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("DynamicModule");
TypeBuilder typeBuilder= moduleBuilder.DefineType("DynamicType", TypeAttributes.Public);
string spaceyName1 = "Spaced Property";
string spaceyName2 = "Spaced-out Property";
// Define the dynamic properties
this.BuildProperty( typeBuilder,
spaceyName1,
"Spacey Property",
"A property with a space in its name.",
typeof(string));
this.BuildProperty( typeBuilder,
spaceyName2,
"Spacey Property",
"A property with a space and a hyphen in its name.",
typeof(string));
// Create and instantiate the dynamic type
Type type = typeBuilder.CreateType();
Object dynamicType = Activator.CreateInstance(type, new object[] { });
// Set the property values
type.InvokeMember( spaceyName1,
BindingFlags.SetProperty,
null,
dynamicType,
new object[] { "Hi there" });
type.InvokeMember( spaceyName2,
BindingFlags.SetProperty,
null,
dynamicType,
new object[] { "Hi again" });
return dynamicType;
}
The resulting class, complete with property names containing spaces and even a hyphen is displayed in a PropertyGrid control.
In my last post, I generated a SQL result set by combining a standard query with associated embedded XML metadata:
Regardless of how such a result set was obtained, my goal was to use it to create a dynamic class on the fly and display that class in a .Net PropertyGrid control.
I started with a default VS 2005 WinForms app. I renamed it and added a PropertyGrid control, whose Dock property was set to Fill. No magic here.
The PropertyGrid is designed to display the public properties of a class while fully respecting the specifics of property type. Writeable properties are editable. Read-only properties are not. Property attributes for Category and Description are respected, if present.
The code below creates a dynamic class having private fields and corresponding public properties which map to the query result set. Setters and getters are created for each record, but the setter may be omitted for read-only properties. No constructor is explicitly defined, but one can be created if there is a need for an overload of the default constructor. Since each class element is created directly from MSIL instructions, I found it useful to keep things as simple as possible. After all, I just needed a shim class to couple my query results to the PropertyGrid.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Data.SqlClient;
using System.Drawing;
using System.Reflection;
using System.Reflection.Emit;
using System.Text;
using System.Threading;
using System.Windows.Forms;
namespace Dynamic_Classes
{
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
this.propertyGrid.SelectedObject = this.BuildDynamicClass();
}
protected object BuildDynamicClass()
{
// Define the dynamic assembly, module and type
AssemblyName assemblyName = new AssemblyName("DynamicAssembly");
AssemblyBuilder assemblyBuilder =
Thread.GetDomain().DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("DynamicModule");
TypeBuilder typeBuilder= moduleBuilder.DefineType("DynamicType", TypeAttributes.Public);
string dataconn = "server=(local);database=dynamic_classes;uid=sa;pwd=password;";
using (SqlConnection cn = new SqlConnection(dataconn))
{
cn.Open();
string sql = "GetWidgetInfo 1";
SqlDataAdapter da = new SqlDataAdapter(sql, cn);
DataTable dt = new DataTable();
da.Fill(dt);
// Create dynamic properties corresponding to query results
foreach (DataRow row in dt.Rows)
{
string name = (string)row["name"];
string category = (string)row["category"];
string description = (string)row["description"];
Type dataType = Type.GetType((string)row["data_type"]);
this.BuildProperty(typeBuilder, name, category, description, dataType);
}
// Create and instantiate the dynamic type
Type type = typeBuilder.CreateType();
Object dynamicType = Activator.CreateInstance(type, new object[] { });
// Set each property's default value
foreach (DataRow row in dt.Rows)
{
string name = (string)row["name"];
Type dataType = Type.GetType((string)row["data_type"]);
object value = row["value"];
value = (Convert.IsDBNull(value)) ? null : Convert.ChangeType(value, dataType);
type.InvokeMember( name,
BindingFlags.SetProperty,
null,
dynamicType,
new object[] { value });
}
return dynamicType;
}
}
protected void BuildProperty( TypeBuilder typeBuilder,
string name,
string category,
string description,
Type fieldType)
{
// Generate the private field/public property name pair
// (field begins w/LC, property begins w/UC)
char[] chars = name.ToCharArray();
chars[0] = char.ToLower(chars[0]);
string fieldName = new string(chars);
chars[0] = char.ToUpper(chars[0]);
string propertyName = new string(chars);
// Create the private field
FieldBuilder fieldBuilder = typeBuilder.DefineField( name,
fieldType,
FieldAttributes.Private);
// Create the corresponding public property
PropertyBuilder propertyBuilder =
typeBuilder.DefineProperty( propertyName,
System.Reflection.PropertyAttributes.HasDefault,
fieldType,
null);
// Define the required set of property attributes
MethodAttributes propertyAttributes = MethodAttributes.Public |
MethodAttributes.SpecialName |
MethodAttributes.HideBySig;
// Build the getter
MethodBuilder getter = typeBuilder.DefineMethod( "get_" + propertyName,
propertyAttributes,
fieldType,
Type.EmptyTypes);
ILGenerator getterIlGen = getter.GetILGenerator();
getterIlGen.Emit(OpCodes.Ldarg_0);
getterIlGen.Emit(OpCodes.Ldfld, fieldBuilder);
getterIlGen.Emit(OpCodes.Ret);
// Build the setter
MethodBuilder setter = typeBuilder.DefineMethod( "set_" + propertyName,
propertyAttributes,
null,
new Type[] { fieldType });
ILGenerator setterIlGen = setter.GetILGenerator();
setterIlGen.Emit(OpCodes.Ldarg_0);
setterIlGen.Emit(OpCodes.Ldarg_1);
setterIlGen.Emit(OpCodes.Stfld, fieldBuilder);
setterIlGen.Emit(OpCodes.Ret);
// Bind the getter and setter
propertyBuilder.SetGetMethod(getter);
propertyBuilder.SetSetMethod(setter);
// Set the Category and Description attributes
propertyBuilder.SetCustomAttribute(
new CustomAttributeBuilder(
typeof(CategoryAttribute).GetConstructor(
new Type[] { typeof(string) }), new object[] { category }));
propertyBuilder.SetCustomAttribute(
new CustomAttributeBuilder(
typeof(DescriptionAttribute).GetConstructor(
new Type[] { typeof(string) }), new object[] { description }));
}
}
}
This illustrates the true power of the PropertyGrid. Simply binding a class with public properties provides an amazing amount of functionality - from a single line of code. The grid provides editors and validation for strings, integer and real numbers and dates. Booleans are presented as True/False dropdowns. Even things like the Font Dialog, Color Picker, etc. work with no modification.
I'll follow up soon with a post on how to add custom editors for nonstandard property types. I'll also cover how changes can be saved to the underlying data source when using dynamic classes.
There are times when records in a table require different sets of metadata to fully describe their function. This is traditionally accomplished through joins with another table (or set of tables) dedicated to describing the metadata. There is nothing at all wrong with this approach, but the same effect may be achieved by storing the metadata in XML format as just another field in the original table. This eliminates the need for multiple tables.
Obviously there are pros and cons to this technique. While the overall database schema is simplified, viewing and editing the XML metadata is cumbersome. Having said that, I've found the tradeoff acceptable in certain scenarios.
Let's consider a table containg a standard field (name) and another field (properties) which will contain the XML metadata.
Two records have been added to the table, although the rest of the article will focus on the Type A Widget.
Here's the XML metadata for the Type A Widget. Several properties have been defined. The attributes may at first appear to be somewhat randomly-chosen. My ultimate goal is to demonstrate using the output to populate a PropertyGrid control via a dynamic shim class, but that's part of an upcoming post. Let that suffice as a current explanation for my choice of property attributes.
<?xml version="1.0"?>
<properties>
<property name="Description"
data_type="System.String"
category="Identifier"
description="A description of the widget.">
This is Widget A.</property>
<property name="Diameter"
data_type="System.Double"
category="Physical Properties"
description="The diameter of the widget.">
3.75</property>
<property name="Length"
data_type="System.Double"
category="Physical Properties"
description="The length of the widget.">
14</property>
<property name="Quantity Available"
data_type="System.Int32"
category="Ordering Information"
description="The number of widgets currently available.">
47</property>
<property name="Date Available"
data_type="System.DateTime"
category="Ordering Information"
description="The date on which the last shipment was received.">
05/05/2006</property>
<property name="Active"
data_type="System.Boolean"
category="Status"
description="Whether or not the widget is currently in production.">
true</property>
</properties>
Now for the fun part - combining the standard field information with the metadata. SQL's OPENXML statement allows us to treat embedded XML as rowset data.
DECLARE @id int
SET @id = 1
DECLARE @handle int
DECLARE @doc nvarchar(2000)
SELECT @doc = [properties] FROM [widget] WHERE [id] = @id
EXEC sp_xml_preparedocument @handle OUTPUT, @doc
SELECT 'Name' AS [name],
'The name of the widget' AS [description],
'Identifier' AS [category],
[name] AS [value],
'System.String' AS [data_type]
FROM [widget]
WHERE [id] = @id
UNION
SELECT [name], [description], [category], [value], [data_type]
FROM OPENXML (@handle, '/properties/property', 2)
WITH (name nvarchar(50) '@name',
description nvarchar(255) '@description',
category nvarchar(50) '@category',
value nvarchar(50) '.',
data_type nvarchar(50) '@data_type')
ORDER BY [category]
EXEC sp_xml_removedocument @handle
And here's the result. Standard field data (Name - row 2) has been combined with embedded XML metadata (everything else). The number of metadata elements is infinitely variable.
