Paul Sheriff's Blog for the Real World

Creating Collections of Entity Objects using Reflection

psheriff — Wed, 06 Mar 2013 22:43:00 GMT

In my last blog posts I have been showing you how to create collection of entity objects using code that is custom for each table and object you create. Well, if you use a little reflection code you can shrink this code quite a bit. Yes, we all know that...(read more)

Join PDSA at DevIntersection Conference - April 8 - 11, 2013

psheriff — Mon, 04 Mar 2013 17:07:00 GMT

Use the Code 'PDSA' when registering and receive $50 off your registration! Top Microsoft Speakers Featured at DevIntersection & SQLIntersection, Including 3 Speakers from PDSA, Inc. Top Microsoft and third-party speakers, including PDSA's Paul Sheriff...(read more)

Creating Collections of Entity Objects using LINQ and Field Method

psheriff — Mon, 25 Feb 2013 17:02:00 GMT

Let’s now look at another advantage of using a DataTable. A lot of developers today are used to using LINQ. After loading data into a DataTable you can iterate using a foreach statement, or you can use LINQ to create a collection of entity objects. The...(read more)

Creating Collections of Entity Objects using LINQ

psheriff — Mon, 11 Feb 2013 15:17:00 GMT

As discussed in my last two blog posts you have a variety of ways to create collections of Entity classes. Using a DataSet or DataTable is a little slower than using a DataReader, but in most cases the difference is in milliseconds so in a real world...(read more)

Building Collections of Entity Classes using a DataReader

psheriff — Tue, 29 Jan 2013 20:45:00 GMT

As discussed in the last blog post, it is a best practice to build entity classes. In the last post we filled a DataTable with Category data and then iterated over that DataTable to create a collection of Entity classes. In this blog post we will use...(read more)

Building Collections of Entity Classes

psheriff — Tue, 29 Jan 2013 16:55:00 GMT

What is an Entity Class An Entity class has properties and typically no methods. An entity class is generally used to hold a single row of data from a table. So, if you have a Category table with the fields CategoryId, CategoryName and Description, you...(read more)

Creating a XAML Tile Control

psheriff — Mon, 22 Oct 2012 17:13:00 GMT

One of the navigation mechanisms used in Windows 8 and Windows Phone is a Tile. A tile is a large rectangle that can have words and pictures that a user can click on. You can build your own version of a Tile in your WPF or Silverlight applications using...(read more)

A WPF Image/Text Button

psheriff — Mon, 01 Oct 2012 16:03:00 GMT

Some of our customers are asking us to give them a Windows 8 look and feel for their applications. This includes things like buttons, tiles, application bars, and other features. In this blog post I will describe how to create a button that looks similar...(read more)

A WPF Image Button

psheriff — Thu, 06 Sep 2012 20:15:00 GMT

Instead of a normal button with words, sometimes you want a button that is just graphical. Yes, you can put an Image control in the Content of a normal Button control, but you still have the button outline, and trying to change the style can be rather difficult. Instead I like creating a user control that simulates a button, but just accepts an image. Figure 1 shows an example of three of these custom user controls to represent minimize, maximize and close buttons for a borderless window. Notice the highlighted image button has a gray rectangle around it. You will learn how to highlight using the VisualStateManager in this blog post.

Figure 1: Creating a custom user control for things like image buttons gives you complete control over the look and feel.

I would suggest you read my previous blog post on creating a custom Button user control as that is a good primer for what I am going to expand upon in this blog post. You can find this blog post at http://weblogs.asp.net/psheriff/archive/2012/08/10/create-your-own-wpf-button-user-controls.aspx.

The User Control

The XAML for this image button user control contains just a few controls, plus a Visual State Manager. The basic outline of the user control is shown below:

<VisualStateManager.VisualStateGroups>
... MORE XAML HERE ...
</VisualStateManager.VisualStateGroups>

There is a Border control named borMain and a single Image control in this user control. That is all that is needed to display the buttons shown in Figure 1. The definition for this user control is in a DLL named PDSA.WPF. The Style definitions for both the Border and the Image controls are contained in a resource dictionary names PDSAButtonStyles.xaml. Using a resource dictionary allows you to create a few different resource dictionaries, each with a different theme for the buttons.

The Visual State Manager

To display the highlight around the button as your mouse moves over the control, you will need to add a Visual State Manager group. Two different states are needed; MouseEnter and MouseLeave. In the MouseEnter you create a ColorAnimation to modify the BorderBrush color of the Border control. You specify the color to animate as “DarkGray”. You set the duration to less than a second. The TargetName of this storyboard is the name of the Border control “borMain” and since we are specifying a single color, you need to set the TargetProperty to “BorderBrush.Color”. You do not need any storyboard for the MouseLeave state. Leaving this VisualState empty tells the Visual State Manager to put everything back the way it was before the MouseEnter event.

<VisualStateManager.VisualStateGroups>
<VisualStateGroup Name="MouseStates">
    <VisualState Name="MouseEnter">
      <Storyboard>
        <ColorAnimation
            To="DarkGray"
            Duration="0:0:00.1"
            Storyboard.TargetName="borMain"
            Storyboard.TargetProperty="BorderBrush.Color" />
      </Storyboard>
    </VisualState>
    <VisualState Name="MouseLeave" />
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>

Writing the Mouse Events

To trigger the Visual State Manager to run its storyboard in response to the specified event, you need to respond to the MouseEnter event on the Border control. In the code behind for this event call the GoToElementState() method of the VisualStateManager class exposed by the user control. To this method you will pass in the target element (“borMain”) and the state (“MouseEnter”). The VisualStateManager will then run the storyboard contained within the defined state in the XAML.

private void borMain_MouseEnter(object sender,
MouseEventArgs e)
{
VisualStateManager.GoToElementState(borMain,
"MouseEnter", true);
}

You also need to respond to the MouseLeave event. In this event you call the VisualStateManager as well, but specify “MouseLeave” as the state to go to.

private void borMain_MouseLeave(object sender,
MouseEventArgs e)
{
VisualStateManager.GoToElementState(borMain,
"MouseLeave", true);
}

The Resource Dictionary

Below is the definition of the PDSAButtonStyles.xaml resource dictionary file contained in the PDSA.WPF DLL. This dictionary can be used as the default look and feel for any image button control you add to a window.

Using the Button Control

Once you make a reference to the PDSA.WPF DLL from your WPF application you will see the “PDSAucButtonImage” control appear in your Toolbox. Drag and drop the button onto a Window or User Control in your application. I have not referenced the PDSAButtonStyles.xaml file within the control itself so you do need to add a reference to this resource dictionary somewhere in your application such as in the App.xaml.

<Application.Resources>
<ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary
        Source="/PDSA.WPF;component/PDSAButtonStyles.xaml" />
    </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>

This will give your buttons a default look and feel unless you override that dictionary on a specific Window or User Control or on an individual button. After you have given a global style to your application and you drag your image button onto a window, the following will appear in your XAML window.

<my:PDSAucButtonImage ... />

There will be some other attributes set on the above XAML, but you simply need to set the x:Name, the ToolTip and ImageUri properties. You will also want to respond to the Click event procedure in order to associate an action with clicking on this button. In the sample code you download for this blog post you will find the declaration of the Minimize button to be the following:

<my:PDSAucButtonImage
       x:Name="btnMinimize"
       Click="btnMinimize_Click"
       ToolTip="Minimize Application"
       ImageUri="/PDSA.WPF;component/Images/Minus.png" />

The ImageUri property is a dependency property in the PDSAucButtonImage user control. The x:Name and the ToolTip we get for free. You have to create the Click event procedure yourself. This is also created in the PDSAucButtonImage user control as follows:

private void borMain_MouseLeftButtonDown(object sender,
MouseButtonEventArgs e)
{
RaiseClick(e);
}

public delegate void ClickEventHandler(object sender,
RoutedEventArgs e);
public event ClickEventHandler Click;

protected void RaiseClick(RoutedEventArgs e)
{
if (null != Click)
Click(this, e);
}

Since a Border control does not have a Click event you will create one by using the MouseLeftButtonDown on the border to fire an event you create called “Click”.

Summary

Creating your own image button control can be done in a variety of ways. In this blog post I showed you how to create a custom user control and simulate a button using a Border and Image control. With just a little bit of code to respond to the MouseLeftButtonDown event on the border you can raise your own Click event. Dependency properties, such as ImageUri, allow you to set attributes on your custom user control. Feel free to expand on this button by adding additional dependency properties, change the resource dictionary, and even the animation to make this button look and act like you want.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “A WPF Image Button” from the drop down list.

A Communication System for XAML Applications

psheriff — Mon, 27 Aug 2012 21:15:00 GMT

In any application, you want to keep the coupling between any two or more objects as loose as possible. Coupling happens when one class contains a property that is used in another class, or uses another class in one of its methods. If you have this situation, then this is called strong or tight coupling. One popular design pattern to help with keeping objects loosely coupled is called the Mediator design pattern. The basics of this pattern are very simple; avoid one object directly talking to another object, and instead use another class to mediate between the two. As with most of my blog posts, the purpose is to introduce you to a simple approach to using a message broker, not all of the fine details.

IPDSAMessageBroker Interface

As with most implementations of a design pattern, you typically start with an interface or an abstract base class. In this particular instance, an Interface will work just fine. The interface for our Message Broker class just contains a single method “SendMessage” and one event “MessageReceived”.

public delegate void MessageReceivedEventHandler(
object sender, PDSAMessageBrokerEventArgs e);

public interface IPDSAMessageBroker
{
void SendMessage(PDSAMessageBrokerMessage msg);

event MessageReceivedEventHandler MessageReceived;
}

PDSAMessageBrokerMessage Class

As you can see in the interface, the SendMessage method requires a type of PDSAMessageBrokerMessage to be passed to it. This class simply has a MessageName which is a ‘string’ type and a MessageBody property which is of the type ‘object’ so you can pass whatever you want in the body. You might pass a string in the body, or a complete Customer object. The MessageName property will help the receiver of the message know what is in the MessageBody property.

public class PDSAMessageBrokerMessage
{
public PDSAMessageBrokerMessage()
{
}

public PDSAMessageBrokerMessage(string name, object body)
{
MessageName = name;
MessageBody = body;
}

public string MessageName { get; set; }

public object MessageBody { get; set; }
}

PDSAMessageBrokerEventArgs Class

As our message broker class will be raising an event that others can respond to, it is a good idea to create your own event argument class. This class will inherit from the System.EventArgs class and add a couple of additional properties. The properties are the MessageName and Message. The MessageName property is simply a string value. The Message property is a type of a PDSAMessageBrokerMessage class.

public class PDSAMessageBrokerEventArgs : EventArgs
{
public PDSAMessageBrokerEventArgs()
{
}

public PDSAMessageBrokerEventArgs(string name,
    PDSAMessageBrokerMessage msg)
{
    MessageName = name;
    Message = msg;
}

public string MessageName { get; set; }

public PDSAMessageBrokerMessage Message { get; set; }
}

PDSAMessageBroker Class

Now that you have an interface class and a class to pass a message through an event, it is time to create your actual PDSAMessageBroker class. This class implements the SendMessage method and will also create the event handler for the delegate created in your Interface.

public class PDSAMessageBroker : IPDSAMessageBroker
{
public void SendMessage(PDSAMessageBrokerMessage msg)
{
PDSAMessageBrokerEventArgs args;

args = new PDSAMessageBrokerEventArgs(
msg.MessageName, msg);

RaiseMessageReceived(args);
}

public event MessageReceivedEventHandler MessageReceived;

protected void RaiseMessageReceived(
    PDSAMessageBrokerEventArgs e)
{
    if (null != MessageReceived)
      MessageReceived(this, e);
}
}

The SendMessage method will take a PDSAMessageBrokerMessage object as an argument. It then creates an instance of a PDSAMessageBrokerEventArgs class, passing to the constructor two items: the MessageName from the PDSAMessageBrokerMessage object and also the object itself. It may seem a little redundant to pass in the message name when that same message name is part of the message, but it does make consuming the event and checking for the message name a little cleaner – as you will see in the next section.

Create a Global Message Broker

In your WPF application, create an instance of this message broker class in the App class located in the App.xaml file. Create a public property in the App class and create a new instance of that class in the OnStartUp event procedure as shown in the following code:

public partial class App : Application
{
public PDSAMessageBroker MessageBroker { get; set; }

protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);

MessageBroker = new PDSAMessageBroker();
}
}

Sending and Receiving Messages

Let’s assume you have a user control that you load into a control on your main window and you want to send a message from that user control to the main window. You might have the main window display a message box, or put a string into a status bar as shown in Figure 1.

Figure 1: The main window can receive and send messages

The first thing you do in the main window is to hook up an event procedure to the MessageReceived event of the global message broker. This is done in the constructor of the main window:

public MainWindow()
{
InitializeComponent();

(Application.Current as App).MessageBroker.
MessageReceived += new MessageReceivedEventHandler(
MessageBroker_MessageReceived);
}

One piece of code you might not be familiar with is accessing a property defined in the App class of your XAML application. Within the App.Xaml file is a class named App that inherits from the Application object. You access the global instance of this App class by using Application.Current. You cast Application.Current to ‘App’ prior to accessing any of the public properties or methods you defined in the App class. Thus, the code (Application.Current as App).MessageBroker, allows you to get at the MessageBroker property defined in the App class.

In the MessageReceived event procedure in the main window (shown below) you can now check to see if the MessageName property of the PDSAMessageBrokerEventArgs is equal to “StatusBar” and if it is, then display the message body into the status bar text block control.

void MessageBroker_MessageReceived(object sender,
   PDSAMessageBrokerEventArgs e)
{
switch (e.MessageName)
{
    case "StatusBar":
      tbStatus.Text = e.Message.MessageBody.ToString();
      break;
}
}

In the Page 1 user control’s Loaded event procedure you will send the message “StatusBar” through the global message broker to any listener using the following code:

private void UserControl_Loaded(object sender,
RoutedEventArgs e)
{
// Send Status Message
(Application.Current as App).MessageBroker.
SendMessage(new PDSAMessageBrokerMessage("StatusBar",
"This is Page 1"));
}

Since the main window is listening for the message ‘StatusBar’, it will display the value “This is Page 1” in the status bar at the bottom of the main window.

Sending a Message to a User Control

The previous example sent a message from the user control to the main window. You can also send messages from the main window to any listener as well. Remember that the global message broker is really just a broadcaster to anyone who has hooked into the MessageReceived event.

In the constructor of the user control named ucPage1 you can hook into the global message broker’s MessageReceived event. You can then listen for any messages that are sent to this control by using a similar switch-case structure like that in the main window.

public ucPage1()
{
InitializeComponent();

// Hook to the Global Message Broker
(Application.Current as App).MessageBroker.
MessageReceived += new MessageReceivedEventHandler(
MessageBroker_MessageReceived);
}

void MessageBroker_MessageReceived(object sender,
PDSAMessageBrokerEventArgs e)
{
// Look for messages intended for Page 1
switch (e.MessageName)
{
    case "ForPage1":
      MessageBox.Show(e.Message.MessageBody.ToString());
      break;
}
}

Once the ucPage1 user control has been loaded into the main window you can then send a message using the following code:

private void btnSendToPage1_Click(object sender,
RoutedEventArgs e)
{
PDSAMessageBrokerMessage arg =
new PDSAMessageBrokerMessage();

arg.MessageName = "ForPage1";
arg.MessageBody = "Message For Page 1";

// Send a message to Page 1
(Application.Current as App).MessageBroker.SendMessage(arg);
}

Since the MessageName matches what is in the ucPage1 MessageReceived event procedure, ucPage1 can do anything in response to that event. It is important to note that when the message gets sent it is sent to all MessageReceived event procedures, not just the one that is looking for a message called “ForPage1”. If the user control ucPage1 is not loaded and this message is broadcast, but no other code is listening for it, then it is simply ignored.

Remove Event Handler

In each class where you add an event handler to the MessageReceived event you need to make sure to remove those event handlers when you are done. Failure to do so can cause a strong reference to the class and thus not allow that object to be garbage collected. In each of your user control’s make sure in the Unloaded event to remove the event handler.

private void UserControl_Unloaded(object sender,
RoutedEventArgs e)
{
if (_MessageBroker != null)
_MessageBroker.MessageReceived -=
_MessageBroker_MessageReceived;
}

Problems with Message Brokering

As with most “global” classes or classes that hook up events to other classes, garbage collection is something you need to consider. Just the simple act of hooking up an event procedure to a global event handler creates a reference between your user control and the message broker in the App class. This means that even when your user control is removed from your UI, the class will still be in memory because of the reference to the message broker. This can cause messages to still being handled even though the UI is not being displayed. It is up to you to make sure you remove those event handlers as discussed in the previous section. If you don’t, then the garbage collector cannot release those objects.

Instead of using events to send messages from one object to another you might consider registering your objects with a central message broker. This message broker now becomes a collection class into which you pass an object and what messages that object wishes to receive. You do end up with the same problem however. You have to un-register your objects; otherwise they still stay in memory. To alleviate this problem you can look into using the WeakReference class as a method to store your objects so they can be garbage collected if need be. Discussing Weak References is beyond the scope of this post, but you can look this up on the web.

Summary

In this blog post you learned how to create a simple message broker system that will allow you to send messages from one object to another without having to reference objects directly. This does reduce the coupling between objects in your application. You do need to remember to get rid of any event handlers prior to your objects going out of scope or you run the risk of having memory leaks and events being called even though you can no longer access the object that is responding to that event.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “A Communication System for XAML Applications” from the drop down list.

A WPF Message Box you can Style

psheriff — Mon, 13 Aug 2012 19:39:00 GMT

You go to great pains to add styles, colors, gradients, and a really cool look and feel to your WPF application only to have that ruined by the standard Windows message box as shown in Figure 1.

Figure 1: The normal Windows message box just does not look right on a styled WPF application.

What would be nice is if Microsoft offered a styled message box. But, they don’t. So it is up to us to create a window that we can style and do whatever we want with it. Thus, I can up with a message box that looks like Figure 2 and Figure 3.

Figure 2: Creating your own dialog from a Window, a Text Block and a custom button control.

Figure 3: You can completely change the theme of your button through the use of resource dictionaries.

The PDSAMessageBoxView XAML

The first step in creating a custom message box is to add a new Window to your WPF project. You then need to set some styles to get a border-less window. You set the following attributes on your Window.

WindowStyle="None"
ShowInTaskbar="True"
ResizeMode=”NoResize”
AllowsTransparency="True"
Background="Transparent"

The WindowStyle attribute normally allows you to set a single border, three-D border, or a Tool Window border. Setting this attribute to None will eliminate the border. The ShowInTaskbar attribute is optional, but if you are doing a dialog window you probably want this window to show up in the Task Bar. Since this is a dialog window, you probably do not want to allow the user to resize this window, thus you set the ResizeMode to “NoResize”. The next two attributes, AllowsTransparency and Background work together. You must set AllowsTransparency to True to allow the Background to be set to Transparent. If you do not set these two attributes, then your border will still show up.

The listing that follows shows the complete XAML for the PDSAMessageBoxView.xaml file. This XAML file contains a Border, a Grid, a TextBlock for the message, and a StackPanel control with four PDSAucButton controls (see my previous blog post on how to create these buttons). All of the attributes for the border, the text block and the buttons are controlled via styles in a Resource Dictionary file. Using a resource dictionary allows you to create new resource dictionaries with different colors and other attributes to style the message box in any manner you see fit.

Styles for PDSAMessageBox Class

As mentioned previously, all of the styles for the PDSAMessageBoxView class are contained within a resource dictionary. There is one resource dictionary in the PDSA.WPF DLL where the PDSAMessageBoxView class is located. However, there is an additional resource dictionary in the main project with a blue theme as shown in Figure 3. The listing below is the complete resource dictionary for the gray message box theme.

Feel free to modify any of the above styles to make the message box look like however you want.

The PDSAMessageBox Class

Just like .NET has the MessageBox class in order to display the dialog, I have created a PDSAMessageBox class with a Show method as well. I made the Show method with the same parameters as the MessageBox class in order to help you make an easier transition to the PDSAMessageBox class. However, I do not use any of the MessageBoxImage parameters, so you will need to remove any of these, or add an image to this view if you so desire. Below is the PDSAMessageBox class with the static Show methods defined.

public class PDSAMessageBox
{
public static MessageBoxResult Show(string message)
{
return Show(message, string.Empty, MessageBoxButton.OK);
}

public static MessageBoxResult Show(string message,
string caption)
{
return Show(message, caption, MessageBoxButton.OK);
}

public static MessageBoxResult Show(string message,
    string caption, MessageBoxButton buttons)
{
    MessageBoxResult result = MessageBoxResult.None;
    PDSAMessageBoxView dialog = new PDSAMessageBoxView();

    dialog.Title = caption;
    dialog.tbMessage.Text = message;
    dialog.Buttons = buttons;
    // If just an OK button, allow the user to just
    // move away from the dialog
    if (buttons == MessageBoxButton.OK)
      dialog.Show();
    else
    {
      dialog.ShowDialog();
      result = dialog.Result;
    }

return result;
}
}

All of the Show methods end up calling just a single Show that takes care of displaying the PDSAMessageBoxView dialog. One thing I did change in my Show method is that if the user pops up a message box with just an “Ok” button, I do allow the user to navigate away from this dialog without pressing the Ok button. To me, it does not make sense to force the user to press a single button on the form. This could have side-effects however, if you have code immediately following the call to the Show method because this is no longer a modal dialog. Again, feel free to modify this code if you do not like this functionality.

Calling the PDSAMessageBox

Below is an example of calling the PDSAMessageBox. The Show method will return a MessageBoxResult enumeration. There was no need to change the return value from that of the normal MessageBox class. This code can be found in the sample that you download along with this blog post.

private void btnOKOnly_Click(object sender, RoutedEventArgs e)
{
PDSAMessageBox.Show("This just displays an OK Button",
"OK", MessageBoxButton.OK);
}

private void btnYesNo_Click(object sender, RoutedEventArgs e)
{
MessageBoxResult result;

result = PDSAMessageBox.Show("Do you want to Quit?",
"Quit?", MessageBoxButton.YesNo);

MessageBox.Show("Result is " + result.ToString());
}

Summary

Creating your own dialog box is very easy using just a little bit of XAML, some styles and a class with a few methods. Break up your styles into resource dictionaries in order to have the flexibility to modify the look and feel of your dialogs. Keep your dialog boxes and buttons in a separate DLL in order to make it easy to reuse your controls.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “A WPF Message Box you can Style” from the drop down list.

Create your own WPF Button User Controls

psheriff — Fri, 10 Aug 2012 18:54:00 GMT

In Figure 1 you can see examples of the standard WPF Button controls. You can add a drop shadow and you can change the color, but you can’t change much else without creating a whole new control template. For example, you are unable to modify the BorderBrush or the BorderThickness properties of the Button control. Additionally you might want to use some other animation than the default, which again requires you to change the control template.

Sometimes all you want to do is to just have some simple buttons where you can modify the border brush and the thickness and have different color options via styles. I have found that instead of working with the whole control template thing, just creating a User Control is sometimes much easier.

Figure 1: The normal WPF Buttons cannot be styled very well.

There are many ways to create custom buttons and there are advantages and disadvantages to each way. The purpose of this blog post is to present one method that is easily understood by almost any XAML programmer, and hopefully to those new to XAML as well. User controls have been around since the Visual Basic 4.0 days. Most developers understand the value of using user controls. With XAML user controls you can put these controls into a WPF User Control Library or a Silverlight Class Library and reference those DLLs from any WPF or Silverlight application. This gives you great reusability. By using resource dictionaries and appropriate use of styles you can make your user controls very customizable as shown in Figure 1. The 2nd row of buttons you see are the same button user control with just different styles applied.

The User Control

The XAML for your Button user control is actually very simple. You use a single Border control and a TextBlock control within that Border as shown in Listing 1.

Listing 1: The XAML for a Button user control is just a Border and TextBlock

The definition for this user control is in a DLL named PDSA.WPF. Notice that there are Style definitions for both the Border and the TextBlock. We used styles contained in a resource dictionary as opposed to setting up dependency properties for each individual attribute that we might want to set. This allows us to create a few different resource dictionaries, each with a different theme for the buttons. You can see the three different themes we created in Figure 1. The Gray Style button uses a resource dictionary that is contained in the PDSA.WPF DLL. The other two styles are in the main project and can be referenced from your App.xaml or from within the Window/User Control where you need the button.

Changing Colors in Response to Mouse Events

When a user moves over a button or presses a button you should give some visual feedback to that user. You can do this with animation using the Visual State Manager or Event Triggers in WPF. To keep things simple for this blog post, I simply respond to the various mouse events and change the Background property to a different color. When the mouse is pressed, I also change the Foreground color of the Text in the TextBlock control. The code for each of the mouse events is shown below.

private void pdsaButtonBorderStyle_MouseEnter(
object sender, MouseEventArgs e)
{
pdsaButtonBorderStyle.Background =
(Brush)this.FindResource("pdsaButtonOverStyle");
}

private void pdsaButtonBorderStyle_MouseLeave(
object sender, MouseEventArgs e)
{
pdsaButtonBorderStyle.Background =
(Brush)this.FindResource("pdsaButtonNormalStyle");
}

private void pdsaButtonBorderStyle_MouseDown(
object sender, MouseButtonEventArgs e)
{
// Save old Foreground Brush
_TextBrush = tbText.Foreground;

pdsaButtonBorderStyle.Background =
   (Brush)this.FindResource("pdsaButtonPressedStyle");
tbText.Foreground =
   (SolidColorBrush)this.FindResource(
     "pdsaButtonTextBlockStylePressed");
}

private void pdsaButtonBorderStyle_MouseUp(
object sender, MouseButtonEventArgs e)
{
RestoreNormal();
}

private void RestoreNormal()
{
pdsaButtonBorderStyle.Background =
(Brush)this.FindResource("pdsaButtonNormalStyle");

tbText.Foreground = _TextBrush;
}

Notice that in the code above that you use the FindResource() method instead of accessing the this.Resources[] collection. That is because you want to be able to set the resource dictionary at any level, not just on this user control. FindResource() will search upward through your UI tree looking for a resource that match the names you see that start with “pdsa”.

You will need a Click event that you can raise when the user clicks on the button. Here is the definition for that Click event.

private void pdsaButtonBorderStyle_MouseLeftButtonUp(
object sender, MouseButtonEventArgs e)
{
RaiseClick(e);
}

public delegate void ClickEventHandler(object sender,
RoutedEventArgs e);

public event ClickEventHandler Click;

protected void RaiseClick(RoutedEventArgs e)
{
if (null != Click)
Click(this, e);

RestoreNormal();
}

The Default Resource Dictionary

Below is the definition of the resource dictionary file contained in the PDSA.WPF DLL. This dictionary can be used as the default look and feel for any button control you add to a window. I have included two additional resource dictionaries in the main project as examples of how you can change the resources to give your buttons a different look. You need to keep the x:Key names the same, but you can change any of the attributes of color or thickness that you want. You can even change from Gradient colors to a SolidColorBrush as you can see I did when you look at the different resource dictionaries.

You can look at the other two Resource Dictionary files when you download the sample.

Using the Button Control

Once you make a reference to the PDSA.WPF DLL from your WPF application you will see the “PDSAucButton” control appear in your Toolbox. Drag and drop the button onto a Window or User Control in your application. I have not referenced the PDSAButtonStyles.xaml file within the control itself so you do need to add a reference to this resource dictionary somewhere in your application such as in the App.xaml.

This will give your buttons a default look and feel unless you override that dictionary on a specific Window/User Control or on an individual button. The “Gray Style” button shown in Figure 1 is what the default button looks like after setting the above code in your App.xaml and then dragging a button onto a Window.

If you wish to give a specific style to just a single button you can override the default by using the code below:

<my:PDSAucButton HorizontalAlignment="Left"
                  Margin="6"
                  Text="Flat Blue Style"
                  x:Name="btn2"
                  Click="btn2_Click"
                  VerticalAlignment="Top">
<my:PDSAucButton.Resources>
    <ResourceDictionary Source="FlatBlueButtonStyles.xaml" />
</my:PDSAucButton.Resources>
</my:PDSAucButton>

If you want to override a series of buttons within one specific StackPanel, or within a specific Window or User Control, you simply set the Resources section for that control as shown below:

In the above sample, all buttons within this StackPanel control are styled using the resource dictionary FlatBlueButtonStyles.xaml.

Summary

Creating your own button control can be done in a variety of ways. You can create a new Button control template, apply styles to change just a few things about a Button, create your own Custom control that inherits from Button, or build a User Control as in this blog post. Which method you choose depends a little on how comfortable you are with each method, and how much control you want over the final details of your new Button. The approach outlined in this blog post is simple and easy to understand and almost anyone can use this technique right away. Feel free to add your own animation to this control or maybe add dependency properties to control the BorderBrush, BorderThickness or any other properties you want.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “Create your own WPF Buttons” from the drop down list.

XML Activator

psheriff — Wed, 01 Aug 2012 13:58:00 GMT

All too often I see people using switch/Select Case statements when using a Factory pattern. The problem with this is if you wish to add the ability to instantiate a new class in your Factory, you need to add a new “case” statement, re-compile the code and redeploy that DLL back out to your client machines, or your server(s). Another way to implement a Factory pattern is to use Reflection and Interfaces to dynamically create an instance of a class. This blog post will show you how to use an XML file, an Interface and the Assembly class to dynamically load a list of assemblies and classes to load into an application at runtime.

An XML File of Assembly/Class Names

You will need a data store to place a list of assembly names and class names that you wish to dynamically create. You could use a database table, but I am going to use an XML file that contains the Assembly Name to load and a Class Name to instantiate from that assembly. Any additional information you wish to add, feel free. In the XML listing below you can see a VendorId, VendorName as well as the AssemblyName and ClassName elements.

<Vendors>
<Vendor>
    <VendorId>1</VendorId>
    <VendorName>Microsoft</VendorName>
    <AssemblyName>Vendor.Microsoft</AssemblyName>
    <ClassName>Vendor.Microsoft</ClassName>
</Vendor>
<Vendor>
    <VendorId>2</VendorId>
    <VendorName>Apple</VendorName>
    <AssemblyName>Vendor.Apple</AssemblyName>
    <ClassName>Vendor.Apple</ClassName>
</Vendor>
<Vendor>
    <VendorId>3</VendorId>
    <VendorName>Google</VendorName>
    <AssemblyName>Vendor.Google</AssemblyName>
    <ClassName>Vendor.Google</ClassName>
</Vendor>
</Vendors>

Load the XML File into a Collection Class

When you have an XML file like that shown above, you will typically create a class with properties that match each element in the XML file. Below is a VendorClass that has properties for each element.

public class VendorClass
{
public int VendorId { get; set; }
public string VendorName { get; set; }
public string AssemblyName { get; set; }
public string ClassName { get; set; }
}

Next you create a collection class using the Generic List<VendorClass> class. In this class there is a LoadVendors() method. This method uses the XElement class to load the Vendors.xml file into memory. LINQ to XML is used to iterate over the XML elements and create a collection of VendorClass objects. This resulting collection of objects is added to the List using the AddRange() method.

public class VendorClasses : List<VendorClass>
{
public VendorClasses LoadVendors()
{
    // Load XML file into memory
    var xElem = XElement.Load(
      GetCurrentDirectory() +
      ConfigurationManager.AppSettings["VendorFile"]);

    // Read Vendors using LINQ to XML
    var vendors = from vend in xElem.Descendants("Vendor")
       select new VendorClass
       {
         VendorId =
           Convert.ToInt32(vend.Element("VendorId").Value),
         VendorName = vend.Element("VendorName").Value,
         AssemblyName = vend.Element("AssemblyName").Value,
         ClassName = vend.Element("ClassName").Value
        };

// Add vendors read in to the List of Vendor classes
this.AddRange(vendors.ToList());

return this;
}
}

To load an XML file you need to find the location on disk. There is a GetCurrentDirectory() method in this class. This method gets the current directory and removes any \bin\Debug from the end of the path if present. This allows you to get the current path whether you are running in Visual Studio or not.

private string GetCurrentDirectory()
{
string path = null;

path = AppDomain.CurrentDomain.BaseDirectory;
if (path.IndexOf("\\bin") > 0)
{
path = path.Substring(0, path.LastIndexOf("\\bin"));
}

if(!path.EndsWith(@"\"))
path += @"\";

return path;
}

Create a Vendor Object Dynamically

Now that you have the list of assembly and class names loaded into a collection you can now create an instance of a specific class. In order to do this you must have an Interface or a base class. I have created an Interface called IVendor. This interface will need to be implemented by each Vendor class that you will be dynamically loading. This interface is located in a separate assembly from all other classes and from the main application. This assembly will need to be referenced by the main application as well as from each assembly where your Vendor classes are located.

public interface IVendor
{
int VendorId { get; set; }
string VendorName { get; set; }
string GetVendorInfo();
}

Below is an example of a vendor class named “Apple” that implements the IVendor interface. The GetVendorInfo() method will simply return a string just so we can verify that the class did get created correctly.

public class Apple : IVendor
{
public int VendorId { get; set; }
public string VendorName { get; set; }

public string GetVendorInfo()
{
return "Apple Corporation";
}
}

Below is another example of a vendor class named “Microsoft” that also implements the IVendor interface.

public class Microsoft : IVendor
{
public int VendorId { get; set; }
public string VendorName { get; set; }

public string GetVendorInfo()
{
return "Microsoft Corporation";
}
}

Each of the above classes are located in separate assemblies as you can see by the AssemblyName element in the XML file. These DLLs do NOT need to be referenced from your project, and in fact, should not be. The Create() method shown below uses the Assembly.LoadFile() method to load the assembly from the current directory. That means that the assembly where each Vendor class is located must be in the current directory for this sample. After the DLL has been loaded, you use the CreateInstance() method on the loaded assembly to load the specific class name. Finally you take the VendorId and the VendorName and place it into the Vendor object’s appropriate properties. This newly created Vendor object is returned from this method.

public class VendorClass
{
// Properties here…

public IVendor Create()
{
    Assembly assm;
    IVendor vendor = null;

    // Load Assembly File
    assm = Assembly.LoadFile(
      AppDomain.CurrentDomain.BaseDirectory +
       AssemblyName + ".dll");

// Create new instance of Class
vendor = (IVendor)assm.CreateInstance(ClassName);

    // Set properties in the Provider class from the XML file
    vendor.VendorId = VendorId;
    vendor.VendorName = VendorName;

return vendor;
}
}

The Sample to Test Activation

To test activating each of these vendor classes I have created a WPF application (Figure 1). The Load Vendors button will call the LoadVendors() method to build the collection of VendorClass objects from the XML file.

Figure 1: A sample to test our activation

Below is the code in the btnLoad_Click event procedure that loads the collection of VendorClass objects.

private void btnLoad_Click(object sender, RoutedEventArgs e)
{
VendorClasses classes = new VendorClasses();

// Load all vendors in the XML file
classes.LoadVendors();
lstVendors.DataContext = classes;
}

Once the VendorClass collection is in the List Box you can click on the list box to fire the SelectionChanged event procedure. In this event procedure you will cast the SelectedItem property of the list box into a VendorClass object. You can then call the Create() method to instantiate the Vendor object by loading the assembly and creating an instance of the Vendor object. After the Vendor object has been created you can call the GetVendorInfo() method to verify that the assembly has been loaded and an instance of the class has been created.

private void lstVendors_SelectionChanged(object sender,
SelectionChangedEventArgs e)
{
VendorClass vendor;
IVendor vend;

// Get the currently selected vendor
vendor = (VendorClass)lstVendors.SelectedItem;
// Create an instance of a Vendor class
vend = vendor.Create();

tbVendorName.Text = vend.GetVendorInfo();
}

Summary

In this blog post you learned how to use LINQ to XML to load a collection of classes that contain information about other classes that you will eventually load. You saw how to use the Assembly class to load an assembly from disk and instantiate a class from a string value. An Interface is used to ensure that each class to be instantiated has the same set of methods and properties. Using this technique can eliminate a switch/Select case statement and allow you to dynamically add classes to any application.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “XML Activator” from the drop down list.

WPF Tree View with Multiple Levels

psheriff — Mon, 23 Jul 2012 17:52:00 GMT

Earlier this year I blogged on how to use the WPF Tree View to view multiple levels. Since then I have had many requests to do the same in WPF. Luckily, the code is almost identical. Here is a blog post on using the WPF Tree View that has multiple levels.

There are many examples of the WPF Tree View that you will find on the web, however, most of them only show you how to go to two levels. What if you have more than two levels? This is where understanding exactly how the Hierarchical Data Templates works is vital. In this blog post, I am going to break down how these templates work so you can really understand what is going on underneath the hood. To start, let’s look at the typical two-level WPF Tree View that has been hard coded with the values shown below:

Figure 1 shows you how this tree view looks when you run the WPF application.

Figure 1: A hard-coded, two level Tree View.

Next, let’s create three classes to mimic the hard-coded Tree View shown above. First, you need an Employee class and an EmployeeType class. The Employee class simply has one property called Name. The constructor is created to accept a “name” argument that you can use to set the Name property when you create an Employee object.

public class Employee
{
public Employee(string name)
{
Name = name;
}

public string Name { get; set; }
}

Create an EmployeeType class that has one property called EmpType and contains a generic List<> collection of Employee objects. The property that holds the collection is called Employees.

public class EmployeeType
{
public EmployeeType(string empType)
{
EmpType = empType;
Employees = new List<Employee>();
}

public string EmpType { get; set; }
public List<Employee> Employees { get; set; }
}

Finally we have a collection class called EmployeeTypes created using the generic List<> class. It is in the constructor for this class where you will build the collection of EmployeeTypes and fill it with Employee objects:

public class EmployeeTypes : List<EmployeeType>
{
public EmployeeTypes()
{
    EmployeeType type;

    type = new EmployeeType("Manager");
    type.Employees.Add(new Employee("Michael"));
    type.Employees.Add(new Employee("Paul"));
    this.Add(type);

    type = new EmployeeType("Project Managers");
    type.Employees.Add(new Employee("Tim"));
    type.Employees.Add(new Employee("John"));
    type.Employees.Add(new Employee("David"));
    this.Add(type);
}
}

You now have a data hierarchy in memory (Figure 2) which is what the Tree View control expects to receive as its data source.

Figure 2: A hierachial data structure of Employee Types containing a collection of Employee objects.

To connect up this hierarchy of data to your Tree View you create an instance of the EmployeeTypes class in XAML as shown in line 13 of Figure 3. The key assigned to this object is “empTypes”. This key is used as the source of data to the entire Tree View by setting the ItemsSource property as shown in Figure 3, Callout #1.

Figure 3: You need to start from the bottom up when laying out your templates for a Tree View.

The ItemsSource property of the Tree View control is used as the data source in the Hierarchical Data Template with the key of employeeTypeTemplate. In this case there is only one Hierarchical Data Template, so any data you wish to display within that template comes from the collection of Employee Types. The TextBlock control in line 20 uses the EmpType property of the EmployeeType class. You specify the name of the Hierarchical Data Template to use in the ItemTemplate property of the Tree View (Callout #2).

For the second (and last) level of the Tree View control you use a normal <DataTemplate> with the name of employeeTemplate (line 14). The Hierarchical Data Template in lines 17-21 sets its ItemTemplate property to the key name of employeeTemplate (Line 19 connects to Line 14). The source of the data for the <DataTemplate> needs to be a property of the EmployeeTypes collection used in the Hierarchical Data Template. In this case that is the Employees property. In the Employees property there is a “Name” property of the Employee class that is used to display the employee name in the second level of the Tree View (Line 15).

What is important here is that your lowest level in your Tree View is expressed in a <DataTemplate> and should be listed first in your Resources section. The next level up in your Tree View should be a <HierarchicalDataTemplate> which has its ItemTemplate property set to the key name of the <DataTemplate> and the ItemsSource property set to the data you wish to display in the <DataTemplate>. The Tree View control should have its ItemsSource property set to the data you wish to display in the <HierarchicalDataTemplate> and its ItemTemplate property set to the key name of the <HierarchicalDataTemplate> object. It is in this way that you get the Tree View to display all levels of your hierarchical data structure.

Three Levels in a Tree View

Now let’s expand upon this concept and use three levels in our Tree View (Figure 4). This Tree View shows that you now have EmployeeTypes at the top of the tree, followed by a small set of employees that themselves manage employees. This means that the EmployeeType class has a collection of Employee objects. Each Employee class has a collection of Employee objects as well.

Figure 4: When using 3 levels in your TreeView you will have 2 Hierarchical Data Templates and 1 Data Template.

The EmployeeType class has not changed at all from our previous example. However, the Employee class now has one additional property as shown below:

public class Employee
{
public Employee(string name)
{
Name = name;
ManagedEmployees = new List<Employee>();
}

public string Name { get; set; }
public List<Employee> ManagedEmployees { get; set; }
}

The next thing that changes in our code is the EmployeeTypes class. The constructor now needs additional code to create a list of managed employees. Below is the new code.

public class EmployeeTypes : List<EmployeeType>
{
public EmployeeTypes()
{
    EmployeeType type;
    Employee emp;
    Employee managed;

    type = new EmployeeType("Manager");
    emp = new Employee("Michael");
    managed = new Employee("John");
    emp.ManagedEmployees.Add(managed);
    managed = new Employee("Tim");
    emp.ManagedEmployees.Add(managed);
    type.Employees.Add(emp);

    emp = new Employee("Paul");
    managed = new Employee("Michael");
    emp.ManagedEmployees.Add(managed);
    managed = new Employee("Cindy");
    emp.ManagedEmployees.Add(managed);
    type.Employees.Add(emp);
    this.Add(type);

Now that you have all of the data built in your classes, you are now ready to hook up this three-level structure to your Tree View. Figure 5 shows the complete XAML needed to hook up your three-level Tree View. You can see in the XAML that there are now two Hierarchical Data Templates and one Data Template. Again you list the Data Template first since that is the lowest level in your Tree View. The next Hierarchical Data Template listed is the next level up from the lowest level, and finally you have a Hierarchical Data Template for the first level in your tree. You need to work your way from the bottom up when creating your Tree View hierarchy. XAML is processed from the top down, so if you attempt to reference a XAML key name that is below where you are referencing it from, you will get a runtime error.

Figure 5: For three levels in a Tree View you will need two Hierarchical Data Templates and one Data Template.

Each Hierarchical Data Template uses the previous template as its ItemTemplate. The ItemsSource of each Hierarchical Data Template is used to feed the data to the previous template. This is probably the most confusing part about working with the Tree View control. You are expecting the content of the current Hierarchical Data Template to use the properties set in the ItemsSource property of that template. But you need to look to the template lower down in the XAML to see the source of the data as shown in Figure 6.

Figure 6: The properties you use within the Content of a template come from the ItemsSource of the next template in the resources section.

Summary

Understanding how to put together your hierarchy in a Tree View is simple once you understand that you need to work from the bottom up. Start with the bottom node in your Tree View and determine what that will look like and where the data will come from. You then build the next Hierarchical Data Template to feed the data to the previous template you created. You keep doing this for each level in your Tree View until you get to the last level. The data for that last Hierarchical Data Template comes from the ItemsSource in the Tree View itself.

NOTE: You can download the sample code for this article by visiting my website at http://www.pdsa.com/downloads. Select “Tips & Tricks”, then select “WPF TreeView with Multiple Levels” from the drop down list.

Read XML Files using LINQ to XML and Extension Methods

psheriff — Sun, 08 Jul 2012 02:46:00 GMT

In previous blog posts I have discussed how to use XML files to store data in your applications. I showed you how to read those XML files from your project and get XML from a WCF service. One of the problems with reading XML files is when elements or attributes are missing. If you try to read that missing data, then a null value is returned. This can cause a problem if you are trying to load that data into an object and a null is read. This blog post will show you how to create extension methods to detect null values and return valid values to load into your object.

The XML Data

An XML data file called Product.xml is located in the \Xml folder of the Silverlight sample project for this blog post. This XML file contains several rows of product data that will be used in each of the samples for this post. Each row has 4 attributes; namely ProductId, ProductName, IntroductionDate and Price.

The Product Class

Just as you create an Entity class to map each column in a table to a property in a class, you should do the same for an XML file too. In this case you will create a Product class with properties for each of the attributes in each element of product data. The following code listing shows the Product class.

public class Product : CommonBase
{
public const string XmlFile = @"Xml/Product.xml";

private string _ProductName;
private int _ProductId;
private DateTime _IntroductionDate;
private decimal _Price;

public string ProductName
{
    get { return _ProductName; }
    set {
      if (_ProductName != value) {
        _ProductName = value;
        RaisePropertyChanged("ProductName");
      }
    }
}

public int ProductId
{
    get { return _ProductId; }
    set {
      if (_ProductId != value) {
        _ProductId = value;
        RaisePropertyChanged("ProductId");
      }
    }
}

public DateTime IntroductionDate
{
    get { return _IntroductionDate; }
    set {
      if (_IntroductionDate != value) {
        _IntroductionDate = value;
        RaisePropertyChanged("IntroductionDate");
      }
    }
}

public decimal Price
{
    get { return _Price; }
    set {
      if (_Price != value) {
        _Price = value;
        RaisePropertyChanged("Price");
      }
    }
}
}

NOTE: The CommonBase class that the Product class inherits from simply implements the INotifyPropertyChanged event in order to inform your XAML UI of any property changes. You can see this class in the sample you download for this blog post.

Reading Data

When using LINQ to XML you call the Load method of the XElement class to load the XML file. Once the XML file has been loaded, you write a LINQ query to iterate over the “Product” Descendants in the XML file. The “select” portion of the LINQ query creates a new Product object for each row in the XML file. You retrieve each attribute by passing each attribute name to the Attribute() method and retrieving the data from the “Value” property. The Value property will return a null if there is no data, or will return the string value of the attribute. The Convert class is used to convert the value retrieved into the appropriate data type required by the Product class.

private void LoadProducts()
{
XElement xElem = null;

try
{
xElem = XElement.Load(Product.XmlFile);

    // The following will NOT work if you have missing attributes
    var products =
        from elem in xElem.Descendants("Product")
        orderby elem.Attribute("ProductName").Value
        select new Product
        {
          ProductId = Convert.ToInt32(
            elem.Attribute("ProductId").Value),
          ProductName = Convert.ToString(
            elem.Attribute("ProductName").Value),
          IntroductionDate = Convert.ToDateTime(
            elem.Attribute("IntroductionDate").Value),
          Price = Convert.ToDecimal(elem.Attribute("Price").Value)
        };

lstData.DataContext = products;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}

This is where the problem comes in. If you have any missing attributes in any of the rows in the XML file, or if the data in the ProductId or IntroductionDate is not of the appropriate type, then this code will fail! The reason? There is no built-in check to ensure that the correct type of data is contained in the XML file. This is where extension methods can come in real handy.

Using Extension Methods

Instead of using the Convert class to perform type conversions as you just saw, create a set of extension methods attached to the XAttribute class. These extension methods will perform null-checking and ensure that a valid value is passed back instead of an exception being thrown if there is invalid data in your XML file.

private void LoadProducts()
{
var xElem = XElement.Load(Product.XmlFile);

var products =
      from elem in xElem.Descendants("Product")
      orderby elem.Attribute("ProductName").Value
      select new Product
      {
        ProductId = elem.Attribute("ProductId").GetAsInteger(),
        ProductName = elem.Attribute("ProductName").GetAsString(),
        IntroductionDate =
           elem.Attribute("IntroductionDate").GetAsDateTime(),
        Price = elem.Attribute("Price").GetAsDecimal()
      };

lstData.DataContext = products;
}

Writing Extension Methods

To create an extension method you will create a class with any name you like. In the code listing below is a class named XmlExtensionMethods. This listing just shows a couple of the available methods such as GetAsString and GetAsInteger. These methods are just like any other method you would write except when you pass in the parameter you prefix the type with the keyword “this”. This lets the compiler know that it should add this method to the class specified in the parameter.

public static class XmlExtensionMethods
{
public static string GetAsString(this XAttribute attr)
{
string ret = string.Empty;

    if (attr != null && !string.IsNullOrEmpty(attr.Value))
    {
      ret = attr.Value;
    }

return ret;
}

public static int GetAsInteger(this XAttribute attr)
{
int ret = 0;
int value = 0;

    if (attr != null && !string.IsNullOrEmpty(attr.Value))
    {
      if(int.TryParse(attr.Value, out value))
        ret = value;
    }

return ret;
}

...
...
}

Each of the methods in the XmlExtensionMethods class should inspect the XAttribute to ensure it is not null and that the value in the attribute is not null. If the value is null, then a default value will be returned such as an empty string or a 0 for a numeric value.

Summary

Extension methods are a great way to simplify your code and provide protection to ensure problems do not occur when reading data. You will probably want to create more extension methods to handle XElement objects as well for when you use element-based XML. Feel free to extend these extension methods to accept a parameter which would be the default value if a null value is detected, or any other parameters you wish.

NOTE: You can download the complete sample code at my website. http://www.pdsa.com/downloads. Choose “Tips & Tricks”, then "Read XML Files using LINQ to XML and Extension Methods" from the drop-down.

Good Luck with your Coding,
Paul D. Sheriff