Using the ASP.NET Dynamic Data features introduced by the .NET Framework SP1 on my new project( a short intensive XP'ish, prototyping),  I was impressed by the fact that in two days I had all entities up and running in a data-entry application.
So I had something to show my client and the future users. They told me what they liked and how they felt the application should be working.
The first thing was that they wanted to search. Not only Filter (what is made possible out-of-the-box), but search, to my surprise this was not possible!

I went to and opened the forum. I asked for the functionality. Scott Hunter, the PM on Dynamic Data answered my question an gave me the following url:
Josh Heyse from Catalyst Software Solutions is responible for this release. It is a dll that holds a DynamicLinqDataSource, DynamicFilterControl and the DynamicFilterForm. You just put it on the page by dragging and dropping.
When we drop the control on the page in the top of the page the following declaration is placed, so the page knows where the dll is containing the control:

   1:  <%@ Register Assembly="Catalyst.Web.DynamicData" Namespace="Catalyst.Web.DynamicData" TagPrefix="search" %>

Listing 1: Register Assembly

In the DynamicLinqDataSource you specify the

  • ContextTypeName (Linq to SQL or Entity Framework Datacontext Typename)
  • TableName (Name of the Table which contains the data you want to show on the page)
   1:  <search:DynamicLinqDataSource ID="GridDataSource" 
   2:                                ContextTypeName="Avanade.Data.MambooDataContext" 
   3:                                TableName="Products" 
   4:                                runat="server" >
   5:  </search:DynamicLinqDataSource>

Listing 2: DynamicLinqDataSource

In the FilterTemplate that is a child of the DynamicFilterForm you put the DynamicFilterControl, the DynamicFilterForm functionally acts like a form tag in HTML. The FilterTemplate, is like the ContentTemplate for AJAX;s UpdatePanel or ItemTemplate for GridView.
In the properties of the DynamicFilterControl we declare the DataField (Field belonging to the Table specified in the TableName of the DynamicLinqDataSource) and the FilterMode (Contains, Equals, MultiSelect, Range)

   1:  <search:DynamicFilterForm DataSourceID="GridDataSource" runat="Server" ID="DynamicFilterForm2">
   2:      <FilterTemplate>
   4:          <asp:Label  ID="FilterTextLabel" 
   5:                      runat="server" 
   6:                      Text="NHL nummer"> 
   7:          </asp:Label>
   9:          <search:DynamicFilterControl ID="DynamicFilterControl1" 
  10:                                       DataField="ProductName" 
  11:                                       FilterMode="Contains" 
  12:                                       Cssclass=""
  13:                                       runat="server">
  14:          </search:DynamicFilterControl>
  16:      </FilterTemplate>
  17:  </search:DynamicFilterForm>

Listing 3: DynamicFilterform containing DynamicFilterControl

Now the user can enter the searchterm ´Dynam´ and find the product ´ASP.NET Dynamic Data´.

Henry cordes
My thoughts exactly...

C# Search dot com

Published 8/9/2008 by Henry in General

Although I use Search dot NET ( quite some time now, I am pleased to announce I found another initiative that I find really helpfull: or 'C# Search'. What I do is add them to my Search Providers in the Search toolbar of Internet Explorer 7.

IE 7 searchproviders

That way when I am coding and need some info, I find answers quick...

Henry Cordes
My thoughts exactly...

CRM 4.0 Login failes 'key expired'

Published 7/24/2008 by Henry in CRM

On our CRM 4.0 Dev environment we experienced the following behaviour:
When opening CRM this message appeared:

The key specified to compute a hash value is expired, only active keys are valid.  Expired Key : CrmKey...

After searching on the machine I found that the Async service did not run, I started it and this solved the issue.

Henry Cordes
My thoughts exactly...

CRM 4.0 Workflow Wait condition bug

Published 6/30/2008 by Henry in CRM

While testing a workflow in CRM 4.0 we encountered the following situation.
The workflow runs when a custom entity is assigned to a person.
In this workflow a wait condition waits until a particular task is completed (activitystatus is completed).
The workflow never stops waiting, even when the task is completed.

You can imagine this is really annoying, I did a support call at Microsoft and after checking some settings, they told us this was a known issue and the were working on the fix.
A few days later we got the fix (KB951919), it is not in the public list of all CRM 4.0 updates and hotfixes, but there is a fix if you need it, just contact MS.

Henry Cordes
My thoughts exactly

Series  - Create a UserControl with Silverlight 2.0 Beta x

Part I   - Create a UserControl with Silverlight 2.0 Beta 1
Part II - Create a UserControl with SilverLight 2.0 Beta  


In my post Create a UserControl with Silverlight 2.0 Beta 1. I started creating a UserControl in Silverlight using Silverlight 2.0 Beta 1, Beta 2 is out now.
Because I want to get familair with Silverlight (WPF, Silverlight should be a subset of WPF and thus IMO a great way to get more knowledge of this technology).

In my first part of the story, I made a UserControl. I did it with the .NET knowledge I already had, but doing so, I completely forgot to RTFM.
Later I did and learned about DependencyProperties. A great other way to work with properties.

A property that is backed by the WPF property system is known as a dependency property.
The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs. These other inputs might include system properties such as themes and user preference, just-in-time property determination mechanisms such as data binding and animations/storyboards, multiple-use templates such as resources and styles, or values known through parent-child relationships with other elements in the element tree. In addition, a dependency property can be implemented to provide self-contained validation, default values, callbacks that monitor changes to other properties, and a system that can coerce property values based on potentially runtime information. Derived classes can also change some specific characteristics of an existing property by overriding dependency property metadata, rather than overriding the actual implementation of existing properties or creating new properties.

The concept is a little overwhelming at first, seeing DependencyProperty code the first time can be confusing.
In Part 1 the HC.Silverlight.TryOut.GenderChooser had the property Gender.

   1:  public GenderChoice Gender
   2:  {
   3:      get { return _Gender; }
   4:      set 
   5:      { 
   6:      _Gender = value;
   7:      SetColorAccordingToChoice();
   8:      OnGenderChosen(this, _Gender);
   9:      }
  10:  }

Listing 1

In the setter of the Gender property, the method SetColorAccordingToChoice is called, this sets the colors of the symbols in a particular way and it fires the OnGenderChosen event.
Every containing control can subscribe to this event and react to changes when it is fired.

Now, in WPF and Silverlight DependencyProperties are available, this property is a great candidate for this concept. But how does it work?
First we refactor our Property  to use GetValue in the setter and SetValue in the setter. We also add a GenderProperty of type DependencyProperty and call the static method Register on the DependencyProperty object:

   1:  public GenderChoice Gender
   2:  {
   3:     get { return (GenderChoice)GetValue(GenderProperty); }
   4:     set { SetValue(GenderProperty, value); }
   5:  }
   7:  public static readonly DependencyProperty GenderProperty =
   8:     DependencyProperty.Register("Gender", typeof(GenderChoice), 
   9:                                           typeof(GenderChooser), 
  10:                                           new PropertyMetadata(
  11:                                           new PropertyChangedCallback(OnGenderChanged)));

Listing 2

Now we got the skeleton to use the DependencyProperty concept in the getter and setter of the property. And we also got a DependencyProperty with the name GenderProperty registered on the FrameworkElement.

Lets analyse the registering of the DependencyProperty. First we look at the signature for the public static Register method on the System.Windows.DependencyProperty class.

   1:  // Summary:
   2:  //     Registers a dependency property with the specified property name, 
   3:  //       property type, owner type, and property metadata for the property.
   4:  //
   5:  // Parameters:
   6:  //   name:
   7:  //     The name of the dependency property to register.
   8:  //
   9:  //   propertyType:
  10:  //     The type of the property.
  11:  //
  12:  //   ownerType:
  13:  //     The owner type that is registering the dependency property.
  14:  //
  15:  //   typeMetadata:
  16:  //     A property metadata instance. 
  17:  //       This can contain a System.Windows.PropertyChangedCallback
  18:  //     implementation reference.
  19:  //
  20:  // Returns:
  21:  //     A dependency property identifier that should be used to set the value of
  22:  //     a public static readonly field in your class. That identifier is then used
  23:  //     to reference the dependency property later, for operations such as setting
  24:  //     its value programmatically.
  25:  public static DependencyProperty Register(string name, 
  26:                                            Type propertyType, 
  27:                                            Type ownerType, 
  28:                                            PropertyMetadata typeMetadata);

Listing 3

The first parameter in the static Register method is name (string). Name is the name of the identifier field that you use to store the name and characteristics of the dependency property must be the Name you chose for the dependency property as part of the Register call appended by the literal string Property.
It is very important to follow the naming pattern, if you fail to designers might not report your property correctly, and certain aspects of property system style application might not behave as expected.

In our example,

  • the name of the dependency property and its CLR accessor is Gender;
  • The identifier field is GenderProperty;
  • The type of the property is GenderChoice;
  • The type that registers the dependency property is GenderChooser;
  • The PropertyMetadata is used to register the PropertyChangedCallback OnGenderChanged on the DependencyProperty, whenever the value in the property changes (is set) this callback is fired. In this callback you put the code to do your validation or any code that needs to run when the value of the property changes. 

So now we need a delegate to declare our EventHandler. The delegate OnGenderChangedEventHandler returns nothing but takes an object and a GenderChoice as parameters.
Furthermore we need a public event GenderChanged and a private static void OnGenderChanged which is the callback function that is fired when the value of the Property changes.

   1:  public delegate void OnGenderChangedEventHandler(object sender, GenderChangedEventArgs e);
   3:  public event OnGenderChangedEventHandler GenderChanged;
   5:  /// <summary>
   6:  /// Raises Event for DependencyProperty
   7:  /// </summary>
   8:  /// <param name="d"></param>
   9:  /// <param name="e"></param>
  10:  private static void OnGenderChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
  11:  {
  12:     if (d is GenderChooser)
  13:     {
  14:         ((GenderChooser)d).SetColorAccordingToChoice(e);
  15:         ((GenderChooser)d).OnGenderChosen((GenderChooser)d, 
  16:                            new GenderChangedEventArgs((GenderChoice)e.NewValue));
  17:     }
  18:  }

Listing 4

This is all the code you need to make a DependencyProperty.
But in our UserControl from Part 1 ,the GenderChooser, we need the GenderChosen event to fire as soon as the value of our Gender property changes. As we see on line 15 of Listing 4 the OnGenderChanged method must be static, because the DependencyProperty.Register method on line 8 of Listing 3 is static and it calls the callback.

Because the callback function OnGenderChanged is static, we need to cast the DependencyObject d to the right object, GenderChooser, after we check if d is of type Genderchooser ofcourse.
Next we call the methods on the calling object itself with the help of a cast (((GenderChooser)d).SetColorAccordingToChoice(e);).

As is shown on line 15 of Listing 4 the OnGenderChosen method is called, which takes an object and a GenderChangedEventArgs, with a GenderChoice as parameter in the constructor, as parameters.
This is the method that will raise the event GenderChosen, if a class is attached to the eventhandler.

So we need the following code to make the event GenderChosen to work.

   1:  // Outside the class!
   2:  public delegate void GenderChosenEventHandler(object sender, GenderChoice gender);
   5:  // public partial class GenderChooser : UserControl
   6:  // {
   8:  public event GenderChosenEventHandler GenderChosen;
  10:  private void OnGenderChosen(object sender, GenderChangedEventArgs e)
  11:  {
  12:      if (GenderChosen != null)
  13:      {
  14:          GenderChosen(sender, e.SelectedGender);
  15:      }
  16:  }

Listing 5

The GenderChosenEventHandler needs to be global, so needs to be outside the class and inside the namespace.
On line 10 (Listing 5) you see GenderChangedEventArgs, this is a class derived from EventArgs with nothing more than a TimeStamp and a GenderChoice property.
So it is easy to pass the SelectedGender in the Event.

GenderChangedEventArgs code

   1:  using System;
   3:  namespace HC.Silverlight.TryOut
   4:  {
   5:      public class GenderChangedEventArgs: EventArgs
   6:      {
   7:          #region Properties
   8:          public DateTime Stamp { get; set; }
   9:          public GenderChoice SelectedGender { get; set; }
  10:          #endregion
  12:          #region C'tors
  13:          public GenderChangedEventArgs(GenderChoice selectedGender)
  14:          {
  15:              Stamp = DateTime.Now;
  16:              SelectedGender = selectedGender;
  17:          }
  18:          #endregion
  19:      }
  20:  }

Listing 6

In Part I Line 36 to 55 the region 'Events' and the region 'EventHandler' can be removed! (thank you, Micheal Ashby (Microsoft) for pointing this out...).

Last but not least, the project is available and can be downloaded here.

DependencyProperties is a well thought out concept it was one of the first things designed when Microsoft started with WPF.
I cannot forget Mark Miller, I attended his session on WPF at the DevDays in Holland, he said: "WPF is designed by geniuses, but implemented by ...", I think the first part means a lot coming from Mark...

Series  - Create a UserControl with Silverlight 2.0 Beta x

Part I   - Create a UserControl with Silverlight 2.0 Beta 1
Part II - Create a UserControl with SilverLight 2.0 Beta  

Henry Cordes
My thoughts exactly...