Josh Smith

Infragistics WPF Controls in a Composite Application

2009-01-12T21:21:00Z

Infragistics recently released the NetAdvantage for Composite Application Library (NCAL) on CodePlex. NCAL enables Infragistics WPF controls to be used in a composite application, based on Microsoft’s Composite Application Library. At this time, the library offers a region adapter for XamDockManager, a sample composite application that uses NCAL, a Quick Start document, and a suite of unit tests that can be used to review the classes it contains.

A composite application consists of independent modules of functionality that are hooked together at run time by an application framework, such as CAL. Each module can inject a View (i.e. a user interface of some kind) into a window of the shell application. The modules can communicate with each other via services registered with the application framework, and subscribe to events with an event broker. This is a popular architecture for large-scale applications built by geographically dispersed teams.

In order for a WPF control to be used in a composite application based on CAL, there must be a region adapter registered for it. Region adapters act as a layer of indirection between the CAL framework and UI controls, allowing a control to be used in a generic fashion by the framework. For example, when CAL adds a View to a Region, the region adapter for XamDockManager must add the View control to an Infragistics docking window. When the user closes the docking window, the region adapter must tell CAL to remove the View from the Region. In this sense, a region adapter keeps a UI control in sync with the state of CAL’s object model.

Composite applications usually have a large number of Views to display in the user interface. A popular way to organize these views is to put them into docking windows, as seen in Visual Studio. XamDockManager provides that frequently needed functionality, which is why we built a region adapter for it first. The NCAL solution contains a sample application which consists of several modules and a shell project, showing the XamDockManagerRegionAdapter in use. If you are interested in using NCAL, be sure to read the Quick Start document, also included in the NCAL solution, because it explains everything you need to know to get started.

If you are building composite applications in WPF, I hope you find NCAL useful. We encourage you to give us your feedback and thoughts about the library!

You can:

Download the latest source code drop on the Source Code page
Start a discussion, or ask a question, about NCAL on the Discussions page
Report a defect on the Issue Tracker page

Happy coding!

Putting Silverlight Commands to Use

2008-11-18T07:39:00Z

In the current release of Silverlight, we have the ICommand interface, which defines a command object, just like in WPF. However, unlike WPF, it seems that Silverlight does not have any built-in support for actually using ICommand objects just yet. This blog post shows how we can work around this shortcoming until the platform has proper support for command sources (such as the ICommandSource interface in WPF). My implementation allows you to execute commands when any ButtonBase-derived control is clicked, pass the command a parameter, and honor the can-execute status of the command (when CanExecute returns false, the button automatically becomes disabled).

In case you are wondering why I bothered implementing this, bear in mind that I’m a huge fan of the Model-View-ViewModel (MVVM) pattern. One of the fundamental principles in MVVM is that the View consumes functionality of the ViewModel by executing commands exposed by the ViewModel. In order to execute a command, you need to have UI controls that are able to do so, such as when a Button executes a command upon being clicked.

I created a static class called ButtonBaseExtensions, which exposes two attached properties. These properties can only be set on ButtonBase subclasses. The Command attached property is of type ICommand, and it allows you to specify which command should execute when the button is clicked. The CommandParameter attached property is of type Object, and is used to pass an optional parameter value to the CanExecute and Execute methods of the command. You can see these two properties in use here:

The main point of interest in the demo app is in the ButtonBaseExtensions class. Here is most of the code involved with the Command attached property. Note, all references to ICommands and ButtonBase objects are stored in WeakReferences, so this will not create a memory leak.

static readonly CommandToButtonsMap s_commandToButtonsMap = new CommandToButtonsMap();

public static ICommand GetCommand(ButtonBase btn)
{
return (ICommand)btn.GetValue(CommandProperty);
}

public static void SetCommand(ButtonBase btn, ICommand value)
{
btn.SetValue(CommandProperty, value);
}

public static readonly DependencyProperty CommandProperty =
    DependencyProperty.RegisterAttached(
    "Command",
    typeof(ICommand),
    typeof(ButtonBaseExtensions),
    new PropertyMetadata(null, OnCommandChanged));

static void OnCommandChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e)
{
    ButtonBase btn = obj as ButtonBase;
    if (btn == null)
        throw new ArgumentException("...");

    ICommand oldCommand = e.OldValue as ICommand;
    if (oldCommand != null)
    {
        s_commandToButtonsMap.RemoveButtonFromMap(btn, oldCommand);
        oldCommand.CanExecuteChanged -= OnCommandCanExecuteChanged;
        btn.Click -= OnButtonBaseClick;
    }

    ICommand newCommand = e.NewValue as ICommand;
    if (newCommand != null)
    {
        s_commandToButtonsMap.AddButtonToMap(btn, newCommand);
        newCommand.CanExecuteChanged += OnCommandCanExecuteChanged;
        btn.Click += OnButtonBaseClick;
    }
}

static void OnCommandCanExecuteChanged(object sender, EventArgs e)
{
    ICommand cmd = sender as ICommand;
    if (cmd != null && s_commandToButtonsMap.ContainsCommand(cmd))
        s_commandToButtonsMap.ForEachButton(cmd, btn =>
        {
            object parameter = ButtonBaseExtensions.GetCommandParameter(btn);
            btn.IsEnabled = cmd.CanExecute(parameter);
        });
}

static void OnButtonBaseClick(object sender, RoutedEventArgs e)
{
    ButtonBase btn = sender as ButtonBase;
    ICommand cmd = ButtonBaseExtensions.GetCommand(btn);
    object parameter = ButtonBaseExtensions.GetCommandParameter(btn);
    if (cmd != null && cmd.CanExecute(parameter))
        cmd.Execute(parameter);
}

Download the demo app here. It was created against Silverlight 2, using Visual Studio 2008 SP1.

How to avoid typing FieldLayout XAML

2008-10-03T21:14:00Z

Here's a trick that was inspired by a recent question in a forum post. XamDataGrid will automatically create FieldLayouts and Fields for you, based on the type of data source you give it. If you want to customize the layouts or fields, you can do so by creating those objects in XAML (or code) and configuring their properties. The downside is that you have to manually type that XAML, which can be time consuming. In this post, I'll show how you can easily leverage XamDataGrid's automatic field generation capabilities in such a way that you don't have to type in all that boilerplate XAML.

The idea is to let the data grid create the FieldLayouts and Fields, and in a handler for the FieldLayoutInitialized event you create some XAML on-the-fly. That XAML can then be written to a file, or to the Windows clipboard, or even to the Output window in Visual Studio. For example, suppose that this is my XAML file:

Here is the code-behind file for that window:

using System.Diagnostics;
using System.Text;
using System.Windows;
using Infragistics.Windows.DataPresenter;
using Infragistics.Windows.DataPresenter.Events;

namespace XamDataGridTest
{
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();

            base.DataContext = Task.Create();
            this.xamDG.FieldLayoutInitialized += this.xamDG_FieldLayoutInitialized;
        }

        void xamDG_FieldLayoutInitialized(object sender, FieldLayoutInitializedEventArgs e)
        {
            string xaml = GetXamlForFieldLayout(e.FieldLayout);
            Debug.WriteLine(xaml);
        }

        static string GetXamlForFieldLayout(FieldLayout fieldLayout)
        {
            StringBuilder buffer = new StringBuilder();

            buffer.AppendLine("<igDP:FieldLayout>");
            buffer.AppendLine(" <igDP:FieldLayout.Fields>");

            foreach (Field field in fieldLayout.Fields)
            {
                if (field.IsExpandableResolved == false)
                {
                    buffer.AppendFormat("    <igDP:Field Name=\"{0}\" />", field.Name);
                    buffer.AppendLine();
                }
            }

            buffer.AppendLine(" </igDP:FieldLayout.Fields>");
            buffer.Append("</igDP:FieldLayout>");

            return buffer.ToString();
        }
    }
}

I suppose a more "robust" solution would be to use either an XmlTextWriter, or some XLinq, here. But, for this simple demo, I'm just using plain string concatenations.

When I run the application by pressing F5 (i.e. in Debug mode), the following XAML is sent to the Output window:

<igDP:FieldLayout>
<igDP:FieldLayout.Fields>
    <igDP:Field Name="ID" />
    <igDP:Field Name="Name" />
    <igDP:Field Name="PriorityLevel" />
    <igDP:Field Name="State" />
</igDP:FieldLayout.Fields>
</igDP:FieldLayout>

Each of those Fields corresponds to a property on the Task class in my application. My data source is hierarchical. The Task class has a property called Notes, which is an array of TaskNote objects. The first time I expand one of the records, the FieldLayout used to display a TaskNote object is initialized. That causes the following XAML to be sent to the Output window:

<igDP:FieldLayout>
<igDP:FieldLayout.Fields>
<igDP:Field Name="CreatedOn" />
<igDP:Field Name="Notes" />
</igDP:FieldLayout.Fields>
</igDP:FieldLayout>

Now I can copy and paste that XAML into my Window's XAML file, adjust the FieldLayouts and Fields as I see fit, and then remove the FieldLayoutInitialized handler so that this design-time code does not run in the production application. The resulting XAML file, after I apply some changes to the Fields, looks like this:

        <igDP:FieldLayout>
          <igDP:FieldLayout.Fields>
            <igDP:Field Name="ID" Visibility="Collapsed" />
            <igDP:Field Name="Name" Label="task name" />
            <igDP:Field Name="PriorityLevel" Label="priority level" />
            <igDP:Field Name="State" Label="status" />
          </igDP:FieldLayout.Fields>
        </igDP:FieldLayout>

        <igDP:FieldLayout>
          <igDP:FieldLayout.Fields>
            <igDP:Field Name="CreatedOn" Label="created" />
            <igDP:Field Name="Notes" Label="notes..." />
          </igDP:FieldLayout.Fields>
        </igDP:FieldLayout>

</igDP:XamDataGrid.FieldLayouts>
</igDP:XamDataGrid>
</Grid>
</Window>

Hopefully this trick will shave some time off your development efforts involving XamDataGrid. Happy coding!

Introducing a new XamDataGrid Behavior: DisplayAdorningEditors

2008-09-15T08:40:00Z

This blog post reviews a technique that can vastly reduce the amount of screen real estate required to display your application’s data in XamDataGrid.

Introduction

In my previous post on this blog, I showed how to display an extra field of data in the adorner layer, instead of putting it into a XamDataGrid cell. Since writing that post, I have spent the entire weekend blissfully working on and expanding that core concept. I managed to extract all of the plumbing code that hosts an editor in the adorner layer into a reusable class. I also vastly enhanced and thoroughly tested this functionality. In this blog post, I am proud to present the fruit of my labor: a new behavior for XamDataGrid called ‘DisplayAdorningEditors’.

Background

Before going forward, let’s first take a step back and review why I built this behavior. Most applications have a core subset of data that users refer to most. When displaying data in a data grid, such as XamDataGrid, it can be tempting to simply display all of the data fields as separate columns in the grid. This is convenient because it takes less time to set up, but in the bigger picture, this is usually not a good idea.

There are, at least, two problems with this approach. The user experience degrades because your users must now look at and sift through reams of irrelevant data. Most people appreciate only seeing what they typically want to see, as long as finding the less frequently needed information is not a challenge. In addition, either showing large amounts of data fields in a data grid requires the grid to be very wide, in which case it uses up more precious screen real estate, or it requires the dreaded horizontal scrolling (which most UI designers generally deem a bad thing).

Ideally, you should only display the most relevant data in XamDataGrid, but make it easy for users to find the other, less frequently used information. This improves the user experience and reduces the amount of screen real estate required by the grid. My DisplayAdorningEditors behavior for XamDataGrid makes it easy to achieve this worthwhile goal.

Using DisplayAdorningEditors

I created a class called XamDataGridBehavior. That class can attach a behavior to XamDataGrid. The attached behavior’s name is DisplayAdorningEditors. When you attach this behavior to a XamDataGrid, you can specify a control to display in the adorner layer directly next to the active cell in the grid. In case you are not familiar with WPF’s adorner layer yet, think of it as a pane of glass on top of your UI, in which any visual elements can render, and it is certain that they will draw on top of the UI underneath (“on top of” with regards to the Z axis, not the Y axis).

Setting the DisplayAdorningEditors attached property to true on the XamDataGrid is only half the battle. You must assign a handler for the RequestAdorningEditor attached event, also exposed by my XamDataGridBehavior class. Your event handling method is invoked when the DisplayAdorningEditors behavior needs to know what control, if any, to display in the adorner layer for the grid’s active cell (i.e. the value returned by its ActiveCell property). Be aware, that event is raised quite often, so your application logic should always provide the same control instance(s), instead of new’ing up fresh control instances every time.

You can set this up in XAML, as seen in the following excerpt from the demo application’s ContaxControl user control:

<igDP:XamDataGrid x:Name="xamDG"
xmlns:igDP="http://infragistics.com/DataPresenter"
xmlns:ext="clr-namespace:XamDataGridExtensions;assembly=XamDataGridExtensions"
ext:XamDataGridBehavior.DisplayAdorningEditors="True"
ext:XamDataGridBehavior.RequestAdorningEditor="OnRequestAdorningEditor"
>
...
</igDP:XamDataGrid>

Here is that user control’s code-behind file:

public partial class ContaxControl : UserControl
{
    readonly ContactEmailControl _contactEmailControl;
    readonly ContactPhoneNumbersControl _contactPhoneNumbersControl;
    readonly ContactPhotoAndNotesControl _contactPhotoAndNotesControl;

    public ContaxControl()
    {
        InitializeComponent();

        _contactEmailControl = new ContactEmailControl();
        _contactPhoneNumbersControl = new ContactPhoneNumbersControl();
        _contactPhotoAndNotesControl = new ContactPhotoAndNotesControl();

        _contactEmailControl.Initialize(this.xamDG);
        _contactPhoneNumbersControl.Initialize(this.xamDG);
        _contactPhotoAndNotesControl.Initialize(this.xamDG);

        base.DataContext = Contact.CreateContacts();
    }

    void OnRequestAdorningEditor(object sender, RequestAdorningEditorRoutedEventArgs e)
    {
        switch (e.AdornedCell.Field.Name)
        {
            case "DisplayName":
                e.AdorningEditor = _contactPhotoAndNotesControl;
                break;

            case "CellPhone":
                e.AdorningEditor = _contactPhoneNumbersControl;
                break;

            case "PersonalEmail":
                e.AdorningEditor = _contactEmailControl;
                break;

            default:
                Debug.Fail("Unexpected Field: " + e.AdornedCell.Field.Name);
                break;
        }

        if (e.AdorningEditor != null)
            e.AdorningEditor.DataContext = e.AdornedCell.Record.DataItem;
    }
}

Another hing to take note of is that your controls hosted in the adorner layer need to have some logic built in that handles keyboard navigation. Since you can use any type of control as an adorning editor, my attached behavior cannot make any assumptions about how to handle keystrokes aimed at your control. If you would like to see an example of how to implement this, in the demo application the keyboard interaction logic is in the ContactAdornerControlBase class.

Also, if you want my XamDataGridBehavior class to move focus to your adorning editor control when the user presses Tab, you must set your control's IsTabStop property to true. If you do not, it is assumed that the user should not be able to navigate into the adorning editor control via the Tab key.

Contax - The Demo Application

The best way to understand what this new behavior can do, and how to use it, is to look at the Contax demo application. Contax is a very simple application that stores a list of personal contact information. All of the data is read-only, except for the optional notes about each contact. The point of this demo is not to see how to build a full-fledge application, but simply to see how to use the DisplayAdorningEditors behavior with XamDataGrid.

This screenshot shows Contax when it first starts up:

The XamDataGrid seen above shows four pieces of information about each contact in the list: gender, name, mobile phone number, and personal e-mail address. The assumption is that the users of Contax would find that information to be the most pertinent to their average use of the program. Naturally, deciding on what information is most pertinent for most users requires, for a real application, market research, user acceptance testing, and other related activities.

Now suppose that the user wants to know more about one of the contacts, perhaps Patricia McClellan. After clicking on Patricia’s cell in the “name” column, the UI discloses more information about her, as seen below:

As seen above, we can now see a photograph, nickname, and notes about Patricia (a.k.a. Trish). If Trish’s photo, nickname, and notes were displayed as separate columns in the data grid, the grid’s width would be considerably larger, and the users would have to look at information that they probably don't care about too often.

At this point, the user decides to give Steven Rottingham a call. She first calls his mobile phone, but Steven does not answer, so she decides to call his office phone instead. To find Steven’s office number, the user clicks on the cell in the “mobile #” column to bring up a list of all phone numbers associated with Steven. Here’s what that looks like:

Now the user decides to send Joe Barkley an e-mail, so she opens his list of e-mail addresses to find the right one. After deciding which address to send the message to, she clicks the button next to that address and her default e-mail client opens up with that address in the To field.

If the user were to shorten the Contax window, and then click on Michelle’s name, the adorning editor displays above Michelle’s row, since there is not enough room to display it underneath.

Download

You can download the source code and demo application here (4.27 MB). The solution compiles in Visual Studio 2008 against NetAdvantage for WPF v8.1.

Adorning XamDataGrid with a Popup Editor

2008-09-13T00:22:00Z

In a recent post on the XamDataGrid Forum someone asked how to add an additional editor to a cell when it goes into edit mode. The scenario is that the data source objects have twenty four numeric properties, and each numeric property is accompanied by a text property that stores an explanation for why the numeric property was modified. This is a common scenario for applications where creating a verbose audit trail is required. The goal was to have the grid display only the numeric properties, but when a cell goes into edit mode, show an additional editor so that the user can explain why he/she is updating the numeric value.

This got me thinking. I decided that putting another editor into the cell, while possible, might not produce the best user experience. In my opinion, such “auxiliary” information should not interfere with the structure and layout of the core data in the grid. I think of an explanation for why a cell’s value has changed as “metadata” about the cell, and, as such, it should be displayed outside of the cell. In this blog post, I’ll show you how I took that metadata and hosted it in the adorner layer.

When you run the demo app, edit the value of a cell, and then press Tab, the UI looks like this (after typing in some text):

In that screenshot, the user edited the first cell in the third row. This is why the "Change Reason" editor appears beneath it. After entering in an explanation for the change, and pressing Tab again, the edited cell has a new background color and a tooltip, which shows the change reason. It looks like this:

Now let’s see how this works. The data source is a collection of my Numbers class, which is defined as:

public class Numbers : INotifyPropertyChanged
{
    double _number1;
    double _number2;
    double _number3;
    string _number1ChangeReason;
    string _number2ChangeReason;
    string _number3ChangeReason;

    public Numbers(double number1, double number2, double number3)
    {
        _number1 = number1;
        _number2 = number2;
        _number3 = number3;
    }

    public double Number1
    {
        get { return _number1; }
        set
        {
            if (_number1 == value)
                return;

            _number1 = value;
            this.OnPropertyChanged("Number1");

            if (this.Number1ChangeReason == null)
                this.Number1ChangeReason = String.Empty;
        }
    }

    public string Number1ChangeReason
    {
        get { return _number1ChangeReason; }
        set
        {
            if (_number1ChangeReason == value)
                return;

            _number1ChangeReason = value;
            this.OnPropertyChanged("Number1ChangeReason");
        }
    }

    // All other NumberX and NumberXChangeReason
    // properties were omitted for clarity.

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    void OnPropertyChanged(string prop)
    {
        if (this.PropertyChanged != null)
            this.PropertyChanged(this, new PropertyChangedEventArgs(prop));
    }

    #endregion
}

Notice how each NumberX property has a corresponding NumberXChangeReason property. When the user types an explanation for why they edited a numeric value, they are putting a value into one of those properties. The editor for the “Change Reason” value is called ChangeReasonEditControl. Its XAML file contains this:

In order to make that control appear directly beneath a modified cell in the XamDataGrid, I use my trusty UIElementAdorner class to inject it into the adorner layer. I won’t show that class here, because it is a good amount of code, but you can see it if you download the demo project.

Look at the Text property binding on the TextBox in the ChangeReasonEditControl. Notice how it is bound to a property named ChangeReason. The Numbers class does not have a property called ChangeReason. In order to allow ChangeReasonEditControl to bind to any of the NumberXChangeReason properties, I had to create a proxy class. That class is a private nested class within the main Window, defined as:

private class ChangeReasonProxy
{
    readonly Numbers _numbers;
    readonly PropertyDescriptor _changeReasonPropDesc;

    public ChangeReasonProxy(Numbers numbers, string changeReasonPropName)
    {
        _numbers = numbers;
        _changeReasonPropDesc = TypeDescriptor.GetProperties(numbers)[changeReasonPropName];
    }

    public string ChangeReason
    {
        get { return _changeReasonPropDesc.GetValue(_numbers) as string; }
        set { _changeReasonPropDesc.SetValue(_numbers, value); }
    }
}

When the adorning editor is displayed, its DataContext is set to an instance of that proxy class. Here’s the code that handles this task:

void CreateProxyForAdorner()
{
    if (_adorner == null || this.xamDG.ActiveCell == null)
        return;

    Numbers numbers = this.xamDG.ActiveCell.Record.DataItem as Numbers;
    string changeReasonPropertyName = this.xamDG.ActiveCell.Field.Name + "ChangeReason";
    _adorner.DataContext = new ChangeReasonProxy(numbers, changeReasonPropertyName);
}

I won’t burden this blog post with all of the code involved, but the final thing to take note of is the Style applied to each Field’s editor. Those Styles apply the tooltip and background color after the user has edited a cell in a Field. Here is the declaration of the first Field in the grid:

<igDP:Field Name="Number1">
<igDP:Field.Settings>
    <igDP:FieldSettings>
      <igDP:FieldSettings.EditorStyle>
        <Style TargetType="{x:Type igEditors:XamNumericEditor}">
          <Setter Property="ToolTip" Value="{Binding Path=DataItem.Number1ChangeReason}" />
          <Setter Property="Background" Value="{StaticResource ModifiedCellBackBrush}" />
          <Style.Triggers>
            <DataTrigger
               Binding="{Binding Path=DataItem.Number1ChangeReason}"
               Value="{x:Null}"
               >
              <Setter Property="Background" Value="Transparent" />
            </DataTrigger>
          </Style.Triggers>
        </Style>
      </igDP:FieldSettings.EditorStyle>
    </igDP:FieldSettings>
</igDP:Field.Settings>
</igDP:Field>

Download the demo project here. This project was built in Visual Studio 2008 using NetAdvantage for WPF v8.1.

Emulating the IsSynchronizedWithCurrentItem Behavior in XamDataGrid

2008-09-09T19:38:00Z

In WPF programming, you often set a list control’s IsSynchronizedWithCurrentItem property to true so that selecting an item in the list will cause the rest of the UI to treat that item as the “current” item to display. In addition, by setting that property to true, if some other control (or line of code) decides to set the current item to a new value, the list control will automatically select that item. This is based on the CurrentItem property of WPF’s built-in ICollectionView interface. You can learn more about this feature of WPF in my MSDN article, ‘Customizing Data Display with Data Binding and WPF’.

XamDataGrid does not yet have a property similar to IsSynchronizedWithCurrentItem. In this blog post, I provide a class that will emulate that functionality. Once the control has native support for this functionality, my stopgap solution will be unnecessary.

I decided to expose this functionality as an attached behavior, so that it is easy to use it from XAML. The XAML below demonstrates how to use the feature:

<igDP:XamDataGrid
DataSource="{Binding}"
local:XamDataGridBehavior.IsSynchronizedWithCurrentItem="True"
/>

When you run the demo app, you will see a XamDataGrid and a ListBox, both bound to the same data source. In the screenshot below, I’ve select an item in one control and it is, due to the magic of ICollectionView, selected in the other control.

In the next screenshot, you can see that I deleted the item with the name ‘David’ from one control, and it is removed from both (because they are both bound to the same data source). Also, notice that both controls now have the item with the name ‘Paco’ selected. All of this happens automatically, since both controls rely on WPF's built-in support for currency management.

I must point out some limitations. It only works properly if the XamDataGrid is showing flat data. If your data source is hierarchical, when you select a child record, the rest of the UI will not recognize the new current item, because it is not in the collection of items to which they are bound. Also, ICollectionView does not support having multiple current items, which means you cannot have multiple selected records in the XamDataGrid that correspond to multiple selected items elsewhere in the UI. That is a limitation imposed by WPF, not the grid control or my implementation.

Download the source code here. The project compiles in Visual Studio 2008 using NetAdvantage for WPF v8.1.

Display Multiple Icons in a XamDataGrid Field

2008-09-06T19:32:00Z

This blog post demonstrates how to, optionally, display multiple icons/images/indicators in an UnboundField of the XamDataGrid. This is a common use case of a data grid control, where one column displays multiple status values. In this example, we have a single column that indicates whether each person displayed in the data grid is an employee and/or customer of some company. When you run the demo program, it looks like this:

Download the demo project here.

The data source in this simple demo is an array of Person objects, where the Person class is defined as:

public class Person
{
    public Person(string firstName, string lastName, bool isEmployee, bool isCustomer)
    {
        this.FirstName = firstName;
        this.LastName = lastName;
        this.IsCustomer = isCustomer;
        this.IsEmployee = isEmployee;
    }

    public string FirstName { get; private set; }
    public string LastName { get; private set; }
    public bool IsEmployee { get; private set; }
    public bool IsCustomer { get; private set; }
}

The values of the two Boolean properties are displayed in the same field, as seen above. That field is declared as an UnboundField object, because it is not bound to a single, specific property on the data source objects. Now let’s see how that UnboundField is configured such that it conditionally displays the two indicators that tell the user if a person is an employee and/or customer.

<igDP:UnboundField Label=" E / C">
<igDP:UnboundField.Settings>
    <igDP:FieldSettings
      AllowEdit="False"
      AllowGroupBy="False"
      AllowResize="False"
      AllowSummaries="False"
      LabelClickAction="Nothing"
      LabelMaxWidth="45" CellMaxWidth="45"
      >
      <igDP:FieldSettings.CellValuePresenterStyle>
        <Style TargetType="{x:Type igDP:CellValuePresenter}">
          <Setter Property="Template">
            <Setter.Value>
              <ControlTemplate TargetType="{x:Type igDP:CellValuePresenter}">
                <DockPanel>
                  
                  <Border
                    DockPanel.Dock="Left"
                    BorderBrush="#FFEEEEEE"
                    BorderThickness="1,0,0,0"
                    />
                  <StackPanel Orientation="Horizontal" HorizontalAlignment="Center">
                    <Grid x:Name="EmployeeIcon" ToolTip="Employee">
                      
                      <Ellipse
                        Fill="#FF444444"
                        Margin="1,0.5,0,0"
                        Width="12" Height="12"
                        />
                      
                      <Ellipse
                        Fill="LawnGreen"
                        Width="12" Height="12"
                        />
                    </Grid>
                    <Grid x:Name="CustomerIcon" Margin="6,0,0,0" ToolTip="Customer">
                      
                      <Ellipse
                        Fill="#FF444444"
                        Margin="1,0.5,0,0"
                        Width="12" Height="12"
                        />
                      
                      <Ellipse
                        Fill="Orange"
                        Width="12" Height="12"
                        />
                    </Grid>
                  </StackPanel>
                </DockPanel>
                
                <ControlTemplate.Triggers>
                  <DataTrigger Binding="{Binding Path=DataItem.IsEmployee}" Value="False">
                    <Setter TargetName="EmployeeIcon" Property="Visibility" Value="Hidden" />
                  </DataTrigger>
                  <DataTrigger Binding="{Binding Path=DataItem.IsCustomer}" Value="False">
                    <Setter TargetName="CustomerIcon" Property="Visibility" Value="Hidden" />
                  </DataTrigger>
                </ControlTemplate.Triggers>
              </ControlTemplate>
            </Setter.Value>
          </Setter>
        </Style>
      </igDP:FieldSettings.CellValuePresenterStyle>
    </igDP:FieldSettings>
</igDP:UnboundField.Settings>
</igDP:UnboundField>

That XAML is rather verbose, because I wanted to add a subtle drop shadow effect to each indicator, but without using the DropShadowBitmapEffect (which is not hardware-accelerated unless running on .NET 3.5 SP1 or later). The template’s triggers are responsible for hiding the indicators that do not apply to a person.

This project was built against NetAdvantage for WPF v8.1 using Visual Studio 2008. You can download the source code here.

Adding CheckBoxes to the Record Selectors in XamDataGrid

2008-09-04T16:44:00Z

This blog post explains how to add CheckBox controls to the record selectors in XamDataGrid. We will also see how to add a CheckBox to the header area above the record selectors, so that you can have Check All / Uncheck All behavior. You can download the demo application here.

The screenshot below shows the demo application in action:

If you were to check Ned's CheckBox, all of the records would be in the checked state, so the header CheckBox would automatically enter the checked state. If you toggle the state of the header CheckBox, all of the other CheckBoxes beneath it would assume that new check state. If you click the button on the bottom, a MessageBox would show you which items are checked and unchecked.

In my demo app, the data objects are of type Person, as seen below:

/// <summary>
/// A simple data object that stores
/// information about a person.
/// </summary>
public class Person
{
    public static Person[] GetPeople()
    {
        return new Person[]
        {
            new Person("Jane", 23),
            new Person("Mike", 45),
            new Person("Ned", 67),
        };
    }

    public Person(string name, int age)
    {
        this.Name = name;
        this.Age = age;
    }

    public int Age { get; private set; }
    public string Name { get; private set; }
}

Notice that the Person class does not have any notion of being "checked." This makes sense, because a person in the real world is not checked or unchecked. In order to extend the semantics of a person, and make changes to a person observable to other objects, I created a PersonViewModel class. That class is below:

/// <summary>
/// A presentation-friendly wrapper for the Person
/// class, which has support for being 'checked.'
/// </summary>
public class PersonViewModel : INotifyPropertyChanged
{
    readonly Person _person;
    bool _isChecked;

    public PersonViewModel(Person person)
    {
        _person = person;
    }

    public bool IsChecked
    {
        get { return _isChecked; }
        set
        {
            if (value == _isChecked)
                return;

            _isChecked = value;

            this.OnPropertyChanged("IsChecked");
        }
    }

    public int Age { get { return _person.Age; } }
    public string Name { get { return _person.Name; } }


    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    void OnPropertyChanged(string prop)
    {
        if (this.PropertyChanged != null)
            this.PropertyChanged(this, new PropertyChangedEventArgs(prop));
    }

    #endregion
}

The XamDataGrid displays a list of PersonViewModel objects. The DataItem property of each DataRecord in the grid references a PersonViewModel. The following Style exists in the XamDataGrid's Resources collection, applying a CheckBox to the record selector of each row.

The collection of PersonViewModel objects to which the XamDataGrid is bound exists in an instance of my CommunityViewModel class. That class serves two purposes. First, it contains the list of PersonViewModel objects in its Members property. Second, it provides a get/set property called AllMembersAreChecked. This property is used to maintain the state of the CheckBox in the header area above the record selectors, and to update the IsChecked property of all PersonViewModel objects when the property is set. Here is the CommunityViewModel class:

public class CommunityViewModel : INotifyPropertyChanged
{
    public CommunityViewModel(List<PersonViewModel> members)
    {
        this.Members = members;

        foreach (PersonViewModel member in members)
            member.PropertyChanged += delegate
            {
                this.OnPropertyChanged("AllMembersAreChecked");
            };
    }

    public List<PersonViewModel> Members { get; private set; }

    public bool? AllMembersAreChecked
    {
        get
        {
            bool? value = null;
            for (int idx = 0; idx < this.Members.Count; ++idx)
            {
                if (idx == 0)
                {
                    value = this.Members[0].IsChecked;
                }
                else if (value != this.Members[idx].IsChecked)
                {
                    value = null;
                    break;
                }
            }

            return value;
        }
        set
        {
            if (value == null)
                return;

            foreach (PersonViewModel member in this.Members)
                member.IsChecked = value.Value;
        }
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    void OnPropertyChanged(string prop)
    {
        if (this.PropertyChanged != null)
            this.PropertyChanged(this, new PropertyChangedEventArgs(prop));
    }

    #endregion
}

The Style used to apply a CheckBox to the header area is quite similar to the one we saw previously. One difference is that this Style explicitly sets the target element's Visibility property to ‘Visible', otherwise we would never see the CheckBox. That Style is below:

Download the demo project here. The demo was built in Visual Studio 2008, using NetAdvantage for WPF v8.1.

Article about xamSalesManager

2008-07-25T16:35:00Z

In the recently released NetAdvantage for WPF v8.1, the xamShowcase application contains a new sample called xamSalesManager. I was the Developer on that project, and worked closely with some talented Visual Designers from the Experience Design Group. The application uses several of our WPF components to create a stellar Executive Dashboard interface for a Regional Sales Manager. The application was structured by applying the Model-View-ViewModel pattern.

You can check out xamSalesManager, and all of the other showcase samples, either by installing the product or by running it in your browser. The XBAP version of xamShowcase is located here:

http://xamples.infragistics.com/

I wrote a whitepaper about the application, which was subsequently edited and posted on CodeProject. If you would like to learn more about how xamSalesManager was designed and implemented, I suggest you check out this article:

http://www.codeproject.com/KB/showcase/InsideXamSalesManager.aspx

Enjoy!

Synchronizing Field Widths between FieldLayouts in XamDataGrid

2008-07-03T00:55:00Z

This blog post shows how to force the width of Fields in a child FieldLayout to have the same width as the Fields in the parent/master FieldLayout. This is a stopgap solution, useful only until XamDataGrid has native support for this feature. The desired result is that the XamDataGrid's top-level records have resizable cells, and the non-resizable cells in child records keep their widths the same as the corresponding cells in their parent record. Also, we will align the text in the child records with the text in the parent record, so that the XamDataGrid ends up looking like this:

In the screenshot above, the XamDataGrid has two master records, each of which represent a country. The master records have child records, which represent states or cities within that country. Every location in the grid has a name and a description, so it makes sense to keep all of the fields the same width and have their values line up. This technique uses the hierarchical display support of XamDataGrid to provide a clean, simple listing of hierarchical data. In addition, if you were to adjust the width of the Field headers or cells in a master record, the corresponding cells in the detail records would resize to the same width.

First, let's examine the XAML in the demo application's main Window that configures the XamDataGrid. The most important parts are bold:

<igDP:XamDataGrid
x:Name="xamDataGrid"
DataSource="{Binding}"
FieldLayoutInitialized="xamDataGrid_FieldLayoutInitialized"
GroupByAreaLocation="None"
>

<igDP:XamDataGrid.Resources>
    
    <Style TargetType="{x:Type igDP:LabelPresenter}">
      <EventSetter
        Event="SizeChanged"
        Handler="OnLabelPresenterSizeChanged"
        />
    </Style>
</igDP:XamDataGrid.Resources>

<igDP:XamDataGrid.DataContext>
    <ObjectDataProvider
      MethodName="GetData"
      ObjectType="{x:Type local:DataSource}"
      />
</igDP:XamDataGrid.DataContext>

<igDP:XamDataGrid.FieldLayouts>
    <igDP:FieldLayout Key="master">
      <igDP:FieldLayout.Fields>
        <igDP:Field Name="ID" Visibility="Collapsed" />
        <igDP:Field Name="Name" />
        <igDP:Field Name="Description">
          <igDP:Field.Settings>
            <igDP:FieldSettings LabelWidth="260" CellWidth="260" />
          </igDP:Field.Settings>
        </igDP:Field>
      </igDP:FieldLayout.Fields>
      <igDP:FieldLayout.FieldSettings>
        <igDP:FieldSettings>
          <igDP:FieldSettings.CellValuePresenterStyle>
            <Style TargetType="{x:Type igDP:CellValuePresenter}">
              <Setter Property="FontWeight" Value="Bold" />
            </Style>
          </igDP:FieldSettings.CellValuePresenterStyle>
        </igDP:FieldSettings>
      </igDP:FieldLayout.FieldSettings>
    </igDP:FieldLayout>

    <igDP:FieldLayout Key="detail">
      <igDP:FieldLayout.Fields>
        <igDP:Field Name="ParentID" Visibility="Collapsed" />
        <igDP:Field Name="Name" />
        <igDP:Field Name="Description" />
      </igDP:FieldLayout.Fields>
      <igDP:FieldLayout.FieldSettings>
        <igDP:FieldSettings AllowResize="False" LabelMaxHeight="0">
          <igDP:FieldSettings.CellValuePresenterStyle>
            
            <Style TargetType="{x:Type igDP:CellValuePresenter}">
              <Setter Property="Margin" Value="-3,0,0,0" />
              <Style.Triggers>
                <DataTrigger
                  Binding="{Binding
                    RelativeSource={RelativeSource AncestorType={x:Type igDP:DataRecordPresenter}},
                    Path=IsMouseOver}"
                  Value="True"
                  >
                  <Setter Property="Margin" Value="-3,0,0,0" />
                </DataTrigger>
                <DataTrigger
                  Binding="{Binding
                    RelativeSource={RelativeSource AncestorType={x:Type igDP:DataRecordPresenter}},
                    Path=IsSelected}"
                  Value="True"
                  >
                  <Setter Property="Margin" Value="-3,0,0,0" />
                </DataTrigger>
              </Style.Triggers>
            </Style>
          </igDP:FieldSettings.CellValuePresenterStyle>
        </igDP:FieldSettings>
      </igDP:FieldLayout.FieldSettings>
      <igDP:FieldLayout.Settings>
        <igDP:FieldLayoutSettings HighlightAlternateRecords="True" />
      </igDP:FieldLayout.Settings>
    </igDP:FieldLayout>
</igDP:XamDataGrid.FieldLayouts>

<igDP:XamDataGrid.FieldSettings>
    <igDP:FieldSettings AllowEdit="False" CellClickAction="SelectRecord" />
</igDP:XamDataGrid.FieldSettings>

</igDP:XamDataGrid>

All of the magic here is done via Styles. The control's Resources collection has a typed Style that targets LabelPresenter. That Style adds a handler to a LabelPresenter's SizeChanged event. This is how we can detect changes to the width of Fields at runtime. The other Style is applied to the child FieldLayout's CellValuePresenterStyle. It ensures that the text in the child record cells is pushed a little to the left, thus ensuring that it lines up with the text in the parent row.

The code-behind is not too complicated. It just handles the SizeChanged event of every LabelPresenter to verify that the child Fields are the same width as the parent Fields. It also handles the FieldLayoutInitialized event of the XamDataGrid so that it can bind the child Field widths to the parent Field widths. The demo Window's code is below:

public partial class Window1 : Window
{
    FieldLayout _masterFieldLayout;

    public Window1()
    {
        InitializeComponent();
    }

    // Invoked when a field in the datagrid is resized.
    void OnLabelPresenterSizeChanged(object sender, SizeChangedEventArgs e)
    {
        var pres = sender as LabelPresenter;
        if (pres == null || pres.Field.Owner != _masterFieldLayout)
            return;

        // Ignore tiny changes because they can lead to infinite layout loops.
        double diff = Math.Abs(pres.Field.Settings.LabelWidth - pres.ActualWidth);
        if (diff <= 1)
            return;

        // Set the LabelWidth property so that the LabelWidthResolved is recalculated.
        // That forces the binding to update the width of the corresponding field in
        // the detail layout.
        pres.Field.Settings.LabelWidth = pres.ActualWidth;
    }

    void xamDataGrid_FieldLayoutInitialized(object sender, FieldLayoutInitializedEventArgs e)
    {
        if (_masterFieldLayout == null)
        {
            _masterFieldLayout = e.FieldLayout;
        }
        else
        {
            // Get all of the visible fields in the master layout.
            List<Field> masterFields =
                (from f in _masterFieldLayout.Fields
                 where f.VisibilityResolved == Visibility.Visible
                 select f)
                .ToList();

            // Get all of the visible fields in the detail layout.
            List<Field> detailFields =
                (from f in e.FieldLayout.Fields
                 where f.VisibilityResolved == Visibility.Visible
                 select f)
                .ToList();

            int iterations = Math.Min(masterFields.Count, detailFields.Count);

            // Bind the width of each field in the detail layout to
            // the resolved/actual width of the corresponding field
            // in the master layout.
            for (int n = 0; n < iterations; ++n)
            {
                BindingOperations.SetBinding(
                    detailFields[ n ].Settings,
                    FieldSettings.LabelWidthProperty,
                    new Binding
                    {
                        Path = new PropertyPath("LabelWidthResolved"),
                        Source = masterFields[ n ]
                    });
            }
        }
    }
}

Download the source code here. The solution was built and tested in Visual Studio 2008, using NetAdvantage for WPF v8.1.

Data Binding the IsVisible Property of ContextualTabGroup

2008-06-27T00:47:00Z

XamRibbon allows you to have groups of tabs that only display when the application is in a certain state or condition. In other words, it offers context-sensitive tab groups. You can use them by adding ContextualTabGroup objects to the ContextualTabGroups property of XamRibbon. If you want to hide a ContextualTabGroup, you simply set its IsVisible property to false.

What if you want to data bind IsVisible to a property on a ViewModel object? Then the situation becomes a little bit more difficult, because ContextualTabGroup is not a visual element and does not exist in the element tree. A brief glance in Mole can prove that this is the case:

Notice how the Visual Tree, on the left, does not contain a ContextualTabGroup instance, but the Visual Tree elements have their DataContext set to an instance of ContextualTabGroup. It turns out that ContextualTabGroup is more like a container for settings, not a full-fledged UI element. One important ramification of this seemingly minor detail is that ContextualTabGroup objects are not in the logical tree, which means they do not have an inheritance context, which means that their properties cannot be data bound like properties of a normal UI element in the element tree.

I recently wrote of a way to work around the fact that some objects declared in XAML do not have an inheritance context, in my “Binding a XamDataGrid Field Property” post. In this post, I will show another, far more elegant, way to deal with this problem. I am basing my work here on the “Model-see, Model-do, and the Poo is Optional” post by Mike Hillberg, of Microsoft.

My objective is simple. I want to have a CheckBox bound to a property on a simple ViewModel class, and the IsVisible property of a ContextualTabGroup bound to that same property. When the CheckBox is checked, the tab group displays.

When the CheckBox is unchecked, the tab group goes away.

The ViewModel class, an instance of which serves as the Window’s DataContext, looks like this:

class MyViewModel: INotifyPropertyChanged
{
    bool _showContextualTabGroup;
    public bool ShowContextualTabGroup
    {
        get { return _showContextualTabGroup; }
        set
        {
            if (value == _showContextualTabGroup)
                return;

            _showContextualTabGroup = value;

            this.OnPropertyChanged("ShowContextualTabGroup");
        }
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    void OnPropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null)
            this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    #endregion
}

The trick to making this work is in my DataContextSpy class. It provides an artificial inheritance context with which the ContextualTabGroup can gain access to the Window’s ViewModel via one simple data binding expression. Naturally, you can use DataContextSpy for much more than just this one particular task. Here is the class definition:

public class DataContextSpy
    : Freezable // Enable ElementName and DataContext bindings
{
    public DataContextSpy()
    {
        // This binding allows the spy to inherit a DataContext.
        BindingOperations.SetBinding(this, DataContextProperty, new Binding());
    }

    public object DataContext
    {
        get { return (object)GetValue(DataContextProperty); }
        set { SetValue(DataContextProperty, value); }
    }

    // Borrow the DataContext dependency property from FrameworkElement.
    public static readonly DependencyProperty DataContextProperty =
        FrameworkElement.DataContextProperty.AddOwner(typeof(DataContextSpy));

    protected override Freezable CreateInstanceCore()
    {
        // We are required to override this abstract method.
        throw new NotImplementedException();
    }
}

Now here is the XAML content of the Window, which contains the XamRibbon and DataContextSpy:

You can download the source code here. Note: this project requires Visual Studio 2008 and NetAdvantage for WPF v7.2 or later to compile.

Persisting XamDataGrid Field Widths between Runs of an Application

2008-06-20T17:47:00Z

XamDataGrid has many great features, but as of NetAdvantage for WPF v7.2, it does not yet provide a generic way to save and load user settings. A common requirement for a grid-centric application is that the columns/fields in the grid retain their widths from one run of the application to the next. I have created a stopgap solution, in the form of a utility class, that we can use until XamDataGrid has native support for this functionality.

I created a class called XamDataGridFieldWidthManager that you can use to handle the saving, loading, and applying of field widths. It will take a XamDataGrid like this...

...and, upon calling its SaveFieldWidths method, it will generate the following XML...

<?xml version="1.0" encoding="utf-8"?>
<field-layouts>
<field-layout id="master">
    <field name="ID" width="52" />
    <field name="Column 1" width="77" />
    <field name="Column 2" width="71" />
    <field name="Column 3" width="148" />
    <field name="Column 4" width="168" />
</field-layout>
<field-layout id="detail">
    <field name="ParentID" width="258" />
    <field name="Whatever" width="190" />
</field-layout>
</field-layouts>

You can save that XML somewhere, and next time that you display that XamDataGrid in your program, you pass the XML back to XamDataGridFieldWidthManager so that those persisted field widths are applied to the new fields.

Here is how the demo program uses XamDataGridFieldWidthManager:

public partial class Window1 : Window
{
    const string SETTINGS_FILE = "field-widths.xml";
    readonly XamDataGridFieldWidthManager _widthManager;

    public Window1()
    {
        this.InitializeComponent();

        _widthManager = this.CreateWidthManager();

        // NOTE: You *must* attach a handler to the RequestFieldLayoutID event.
        _widthManager.RequestFieldLayoutID += this.OnWidthManagerRequestFieldLayoutID;
    }

    XamDataGridFieldWidthManager CreateWidthManager()
    {
        StreamReader streamReader = null;
        try
        {
            XmlReader xmlReader = null;

            if (File.Exists(SETTINGS_FILE))
            {
                streamReader = new StreamReader(SETTINGS_FILE);
                xmlReader = XmlReader.Create(streamReader);
            }

            return new XamDataGridFieldWidthManager(this.xamDataGrid, xmlReader);
        }
        finally
        {
            if (streamReader != null)
                streamReader.Dispose();
        }
    }

    void OnWidthManagerRequestFieldLayoutID(object sender, RequestFieldLayoutIDEventArgs e)
    {
        // Provide a unique identifier for each of the FieldLayouts in the XamDataGrid.

        if (e.FieldLayout.Key == this.xamDataGrid.DataSource)
            e.UniqueID = "master";
        else
            e.UniqueID = "detail";
    }

    protected override void OnClosing(CancelEventArgs e)
    {
        base.OnClosing(e);

        if (!e.Cancel)
        {
            // Save the field widths to disk.
            var settings = new XmlWriterSettings { Indent = true };
            using (var xmlWriter = XmlWriter.Create(SETTINGS_FILE, settings))
                _widthManager.SaveFieldWidths(xmlWriter);
        }
    }
}

It is important to note that you must hook the RequestFieldLayoutID event and, in that event handling method, supply a unique identifier for each FieldLayout in the XamDataGrid. This is necessary because XamDataGridFieldWidthManager must be able to map a <field-layout> XML element to a FieldLayout object, but it has no way to produce the same unique identifier for the same logical FieldLayout across runs of the application. Since I have no way to do that in a generic fashion, I consult the class's consumer for that information.

Download the source code and demo project here. You must have Visual Studio 2008 and NetAdvantage for WPF v7.2 or later installed.

Putting a CheckBox in the cells of an UnboundField of XamDataGrid

2008-06-17T02:36:00Z

This blog post demonstrates the correct way to put a CheckBox into the cell of an unbound field for each row in a XamDataGrid. The demo application allows the user to dynamically add and remove customers from a 3D Pie Chart, to compare their total sales against each other. The image below is a screenshot of this demo:

The “Compare” field on the left-hand side is an “unbound field.” This means that it does not have a corresponding property on the data source object to which it is bound. You can add as many UnboundField objects into a FieldLayout as you like.

This demo application’s data source is an array of my Customer class, as seen below:

public class Customer
{
    public Customer(int id, string name, double totalSales)
    {
        this.ID = id;
        this.Name = name;
        this.TotalSales = totalSales;
    }

    public int ID { get; private set; }
    public string Name { get; private set; }
    public double TotalSales { get; private set; }
}

The window contains a XamDataGrid and XamChart. When the user checks a CheckBox in a row of the grid, we add the corresponding Customer’s data to the chart. Here is the XAML declaration of the XamDataGrid:

<igDP:XamDataGrid
Grid.Row="0"
AutoFit="True"
DataSource="{Binding}"
InitializeRecord="XamDataGrid_InitializeRecord"
Theme="Office2k7Black"
>
<igDP:XamDataGrid.CommandBindings>
    
    <CommandBinding
      Command="local:Commands.ShowInChart"
      CanExecute="ShowInChart_CanExecute"
      Executed="ShowInChart_Executed"
      />
</igDP:XamDataGrid.CommandBindings>

<igDP:XamDataGrid.Resources>
    
    <Style
      x:Key="ShowInChartCellStyle"
      TargetType="{x:Type igDP:CellValuePresenter}"
      >
      <Setter Property="Template">
        <Setter.Value>
          <ControlTemplate TargetType="{x:Type igDP:CellValuePresenter}">
            <CheckBox
              Command="local:Commands.ShowInChart"
              CommandParameter="{Binding Path=DataItem}"
              HorizontalAlignment="Center"
              IsChecked="{Binding
                  RelativeSource={RelativeSource TemplatedParent},
                  Path=Value,
                  Mode=TwoWay}"
              VerticalAlignment="Center"
              />
          </ControlTemplate>
        </Setter.Value>
      </Setter>
    </Style>

    
    <Style
      x:Key="TotalSalesEditorStyle"
      TargetType="{x:Type igEditors:ValueEditor}"
      >
      <Setter Property="Format" Value="c" />
    </Style>
</igDP:XamDataGrid.Resources>

<igDP:XamDataGrid.FieldLayouts>
    <igDP:FieldLayout>
      <igDP:FieldLayout.Fields>
        <igDP:UnboundField Name="ShowInChart" Label="Compare">
          <igDP:UnboundField.Settings>
            <igDP:FieldSettings
              CellMaxWidth="70" LabelMaxWidth="70"
              CellValuePresenterStyle="{StaticResource ShowInChartCellStyle}"
              />
          </igDP:UnboundField.Settings>
        </igDP:UnboundField>
        <igDP:Field Name="ID">
          <igDP:Field.Settings>
            <igDP:FieldSettings
              CellMaxWidth="40"
              LabelMaxWidth="40"
              />
          </igDP:Field.Settings>
        </igDP:Field>
        <igDP:Field Name="Name" Label="Customer Name" />
        <igDP:Field Name="TotalSales" Label="Total Sales">
          <igDP:Field.Settings>
            <igDP:FieldSettings
              EditorStyle="{StaticResource TotalSalesEditorStyle}"
              />
          </igDP:Field.Settings>
        </igDP:Field>
      </igDP:FieldLayout.Fields>
    </igDP:FieldLayout>
</igDP:XamDataGrid.FieldLayouts>
</igDP:XamDataGrid>

In the grid’s FieldLayouts section, there is one FieldLayout being created. It’s first field is our UnboundField, named “ShowInChart.” Notice that its CellValuePresenterStyle property is set to reference the “ShowInChartCellStyle” Style, which is declared above. That Style applies a ControlTemplate to the CellValuePresenter in each cell of that field. The ControlTemplate specifies that a CheckBox control should be displayed in the cell. Looking closely at the CheckBox declaration, you can see that it’s IsChecked property is bound to its TemplatedParent, which in this case is the CellValuePresenter being templated. We need to establish this two-way binding against the CellvaluePresenter’s Value property so that the CheckBox and cell value are kept in sync with each other. If we did not do this, the grid would be in an inconsistent state.

When the Window loads up and the XamDataGrid is populated with data, the grid’s InitializeRecord event is handled for each row. That code initializes the unbound field’s cell value to false, as seen below:

void XamDataGrid_InitializeRecord(object sender, InitializeRecordEventArgs e)
{
    // Initialize each ShowInChart cell to false.
    DataRecord dataRecord = e.Record as DataRecord;
    if (dataRecord != null)
        dataRecord.Cells["ShowInChart"].Value = false;
}

So far so good, but what happens when the user checks or unchecks one of those CheckBoxs? How does the program know which Customer’s CheckBox was affected, and when it is changed? This problem can be solved in several ways, but I prefer to use routed commands for this type of task. In the demo app, the Commands.cs file contains this class:

public static class Commands
{
public static readonly RoutedCommand ShowInChart = new RoutedCommand();
}

As seen in the XAML declaration previously, the XamDataGrid is given a CommandBinding for the ShowInChart command. The command’s events are handled in the window’s code-behind, as seen below:

void ShowInChart_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
    // The ShowInChart command can execute if
    // the parameter references a Customer.
    e.CanExecute = e.Parameter is Customer;
}

void ShowInChart_Executed(object sender, ExecutedRoutedEventArgs e)
{
    Customer cust = e.Parameter as Customer;
    if (cust != null)
        this.AddOrRemoveCustomer(cust);
}

void AddOrRemoveCustomer(Customer cust)
{
    DataPointCollection dataPoints = this.chart.Series[0].DataPoints;

    string label = "Cust #" + cust.ID;

    // Check if the customer is in the chart already.
    var dataPoint = dataPoints.FirstOrDefault(dp => dp.Label == label);

    if (dataPoint == null)
    {
        // Add the customer to the pie chart.
        string tooltip =
            String.Format(
            "Name: {0} {1} Total Sales: {2}",
            cust.Name,
            Environment.NewLine,
            cust.TotalSales.ToString("c"));

        dataPoint = new DataPoint
        {
            Label = label,
            Value = cust.TotalSales,
            ToolTip = tooltip
        };

        dataPoints.Add(dataPoint);
    }
    else
    {
        // Remove the customer from the pie chart.
        dataPoints.Remove(dataPoint);
    }
}

You can download the demo source code here. You must have Visual Studio 2008 and NetAdvantage for WPF v7.2 (or later) installed to compile and run this project.

Binding a XamDataGrid Field Property

2008-06-06T05:53:00Z

I recently needed to bind the Visibility of a Field in a XamDataGrid to a property on my ViewModel. I wanted to provide a way for the user to show/hide a column of images in the data grid. My ViewModel object is a POCO (Plain Old Clr Object) that implements INotifyPropertyChanged, and represents the data and UI state of my Window. Unfortunately a Field object is not in the element tree and does not derive from Freezable, which means it does not have an inheritance context, thus its properties cannot participate in normal WPF data binding.

If/when WPF eventually provides a way to give any object an inheritance context, this won't be an issue, but for now there is no clean way to bind a Field's properties to objects inherited down the logical tree, or to the properties of other elements. This blog post shows a workaround that I came up with, allowing me to easily bind the Visibility of a Field to any object.

Here is the basic idea of what I'm trying to accomplish. First the grid displays a column of images:

If you then click the "Show Photos" CheckBox in the ToolBar, the column of photos is hidden, as seen below:

Here is the code-behind of the Window:

public partial class Window1 : Window
{
    public Window1()
    {
        Person[] people = new Person[]
        {
            new Person("Boss Hogg", 42, "hogg.jpg"),
            new Person("Johann Bach", 50, "bach.jpg"),
            new Person("Mugatu", 39, "mugatu.gif"),
            new Person("Simon Wolcott", 24, "wolcott.jpg")
        };

        base.DataContext = new CommunityViewModel(people);
        Application.Current.Resources.Add("DATA_CommunityViewModel", base.DataContext);

        InitializeComponent();
    }
}

Notice that I'm adding the CommunityViewModel class to both the DataContext of the Window and the Resources of the App. I set the DataContext to the ViewModel so that the XamDataGrid and CheckBox controls can bind to its properties. I add it to the App's Resources so that the Field's Visibility binding can access it. Here is the CommunityViewModel class:

class CommunityViewModel : INotifyPropertyChanged
{
    bool _showPhotos;

    public CommunityViewModel(IList<Person> constituents)
    {
        this.Constituents = new ReadOnlyCollection<Person>(constituents);
        _showPhotos = true;
    }

    public ReadOnlyCollection<Person> Constituents { get; set; }

    public bool ShowPhotos
    {
        get { return _showPhotos; }
        set
        {
            if (value == _showPhotos)
                return;

            _showPhotos = value;

            this.OnPropertyChanged("ShowPhotos");
        }
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    void OnPropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null)
            this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    #endregion
}

The magic happens in the XAML. Pay close attention to the 'Photo' Field declaration:

You can download the demo source code here. You will need to have the Infragistics NetAdvantage for WPF installed to run the application.

Using a ViewModel to harness the power of the WPF TreeView

2008-05-23T17:33:00Z

Microsoft's WPF TreeView control can be very difficult to work with, if you try to use it the same way that you program against a Windows Forms TreeView. WPF's TreeView is much more feature-rich and powerful, such as having support for data binding and full visual customizations. Those powers make the control more complicated than the WinForms equivalent. It can be difficult to use, but it does not have to be!

The key to using the WPF TreeView control properly is to provide it with a ViewModel, essentially an abstraction of the tree's state. The TreeView binds to its ViewModel, allowing your code to ignore the TreeView altogether. Once you start programming against your ViewModel abstraction, it is very easy to leverage the power of the TreeView. I published an article about this topic on CodeProject. If you are interested in learning more about it, here's the link: http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx