Wednesday, April 14, 2010

Generic Property Merge Using Reflection

I have found this generic merge method to be very useful. Before you cut and paste it into you Silverlight application, let me explain why I created it.

  1. public virtual bool MergeValues(object oSource, bool bNotifyUI)
  2. {
  3. bool bSucess = true;
  4. foreach (var oPropInfo in oSource.GetType().GetProperties())
  5. {
  6. if (!oPropInfo.CanRead !oPropInfo.CanWrite oPropInfo.Name == "Item")
  7. continue;
  8. var oResult = oPropInfo.GetValue(oSource, null);
  9. if (oResult != oPropInfo.GetValue(this, null))
  10. try
  11. {
  12. oPropInfo.SetValue(this, oResult, null);
  13. if (bNotifyUI)
  14. NotifyOfPropertyChange(oPropInfo.Name);
  15. }
  16. catch
  17. {
  18. bSucess = false;
  19. }
  20. }
  21. return bSucess;
  22. }

Once Silverlight binds a property to a XAML element, your program will perform a lot better if you just change the value rather then rebind to a new object. I have not done any detailed timing tests, but by using this code in a before / after way you can “feel” that this is faster.

I know there is a performance cost when you access a property via reflection, but I am willing to pay that cost to have a solution that is VERY reliable.

By defining this method as virtual you are able to override to build a version that performs better, for example:

  1. public override bool MergeValues(object oSource, bool bNotifyUI)
  2. {
  3. bool bSucess = true;
  4. Person oPerson = oSource as Person;
  5. this.ID = oPerson.ID;
  6. this.FirstName = oPerson.FirstName;
  7. this.MiddleName = oPerson.MiddleName;
  8. this.LastName = oPerson.LastName;
  9. this.MostRecentFlight = oPerson.MostRecentFlight;
  10. return bSucess;
  11. }

But this solution is not as reliable and requires me to change the code every time I modify the properties in this class.

Feel free to cut, paste and modify this code to meet your own coding objectives.

Sunday, March 21, 2010

NCAA Brackets in Silverlight

The developers at a company we were working with put out a challenge -- can you write software to pick the brackets in the NCAA basketball tournament? The answer is you can and 6 of us did. Our solutions range from random number generators to multivariate stepwise regressions. We did the multivariate stepwise regression.

I created a Silverlight application to display the results; that is, Debra designed the application and I did the software. The code is posted to codeplex here, and you can see our picks at

The code is very object oriented and uses a direct approach to pushing the data into the view. No MV-VM was necessary, but that was because of the nature of the solution. This application simply creates a report of our picks, and the picks are shoved into the brackets using a "plug and chug" technique of matching textbox names with ID's in a collection.

I think this code may be useful for other developers who need to manage a tournament.

You can get the source code on codeplex:

Thursday, February 25, 2010

Another Way to Think about Code Reuse

Anyone who practices Object Oriented Programming has a lot of different ways to reuse code. The most common way is to use inheritance, but recently I have been reusing code in an unconventional way.

Whenever I create a class I follow a strict convention on naming properties. Here is an example:

  1. public class Movie
  2. {
  3.     public string Title { get; set; }
  4.     public List<People> Actors { get; set; }
  6.     public DateTime ReleaseDate { get; set; }
  7.     public double MoneyEarnedToDate { get; set; }
  9.     public string Producer { get; set; }
  10.     public string Genre { get; set; }
  11. }

CamelCase is the convention I use to define every property. I always use complete words and never use abbreviations. I do not use underscores in public properties. I stick to this convention because it lets me extract Meta data from the class while it is in use and can be used to simplify coding of the UI.

  1. public class CustomGrid : DataGrid
  2. {
  3.     public CustomGrid()
  4.         : base()
  5.     {
  6.         AutoGenerateColumns = true;
  7.         AutoGeneratingColumn += new EventHandler<DataGridAutoGeneratingColumnEventArgs>(OnAutoGeneratingColumn);
  8.     }
  10.     void OnAutoGeneratingColumn(object sender, DataGridAutoGeneratingColumnEventArgs e)
  11.     {
  12.         string sHeader = e.Column.Header.ToString();
  13.         e.Column.Header = CamelToTitleCase(sHeader);
  14.     }
  16.     public string CamelToTitleCase(string Text)
  17.     {
  18.         Text = Text.Substring(0, 1).ToUpper() + Text.Substring(1);
  19.         return Regex.Replace(Text, @"(\B[A-Z])", @" $1");
  20.     }
  22. }

Via inheritance I can customize the standard Silverlight DataGrid to automatically generate columns for whatever class is bound to it. I sign up for the OnAutoGeneratingColumn event so I can rename the column headings. The function CamelToTitleCase will automatically insert spaces before each capitol letter, so the property ReleaseDate becomes the header Release Date and the property MoneyEarnedToDate becomes Money Earned To Date

So is using a coding convention really code reuse or is it more like asset repurposing? I have learned that having a convention makes my code easier to read and debug. It also leads to even more advanced techniques I will share in later blogs.