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;
5. foreach (var oPropInfo in oSource.GetType().GetProperties())
6. {
7. if (!oPropInfo.CanRead !oPropInfo.CanWrite oPropInfo.Name == "Item")
8. continue;
10. var oResult = oPropInfo.GetValue(oSource, null);
11. if (oResult != oPropInfo.GetValue(this, null))
12. try
13. {
14. oPropInfo.SetValue(this, oResult, null);
15. if (bNotifyUI)
16. NotifyOfPropertyChange(oPropInfo.Name);
17. }
18. catch
19. {
20. bSucess = false;
21. }
22. }
23. return bSucess;
24. }

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;
6. this.ID = oPerson.ID;
7. this.FirstName = oPerson.FirstName;
8. this.MiddleName = oPerson.MiddleName;
9. this.LastName = oPerson.LastName;
10. this.MostRecentFlight = oPerson.MostRecentFlight;
12. return bSucess;
13. }

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.

Know Your Parents and Grandparents

In programming Silverlight I have come across situations where a control or framework element needs to access information on its parent. The code to get information off your direct parent is simple:

1.             var oContent = this.Parent.ReadLocalValue(Content);

for example.

The real power of Silverlight is in the declarative nesting of XAML elements, and that means that the type of your direct parent may not always be known. To clarify, if you drop a control on a Page, then the Page object will be your parent. However if you then wrap your control in a ScrollViewer, the ScrollViewer becomes your parent and the Page becomes your grandparent.

To avoid all these issues I include the following code in most of my Silverlight projects:

1.         public virtual T ParentOfType<T>() where T : FrameworkElement
2.         {
3.             Type oType = typeof(T);
4.             var oParent = Parent as FrameworkElement;
5.             while (oParent != null)
6.             {
7.                 if (oType.IsInstanceOfType(oParent))
8.                     return oParent as T;
9.  
10.                 if (oParent.GetType() == oType)
11.                     return oParent as T;
12.  
13.                 oParent = oParent.Parent as FrameworkElement;
14.             }
15.             return null;
16.         }

Recently I needed to access the Navigation Service that is part of a Silverlight Page object. Using the method above I wrote this code to access the service:

1.         void OnMouseLeftButtonDown(object sender, MouseButtonEventArgs e)
2.         {
3.             var oPage = ParentOfType<Page>();
4.  
6.             if ( oPage != null )
7.                 oPage.NavigationService.Navigate(new Uri(NavigateUri, UriKind.RelativeOrAbsolute));
8.         }

Now regardless where this control is placed in the XAML, the Navigation Service will execute correctly.