Xceed Community

Xceed at Mix10!

Matt — Tue, 02 Mar 2010 18:24:00 GMT

Feels like not too long ago I was writing about Xceed going to Mix09 and here we are a year later, ready to go to Mix10! We are all very excited about the announcements that will be made in regards to Windows Phone 7 Series development and are looking forward to some announcements about Silverlight's future as well. And who knows, maybe even WPF? Come on Microsoft, give WPF some love! :).

That said, if you catch Cat, Odi, Charles, or myself at the event and have questions about our products, don't be shy and come talk to us! We'll be staying at the Mandalay Bay hotel and will try to be part of social events there. You can check us out as usual on twitter (@MattD1980 @Cattatatow @Kosmatos) to see where we're hanging out.

I hope the keynotes and sessions this year will be as inspiring as last year. Mix09 by far surpassed my expectations and it would seem that even more is brewing in Microsoft's lair. I still have to fill my schedule with the sessions I will be attending. So much to learn, so little time!

See you there and don't hesitate to contact us if you want to meet up!

Xceed DataGrid for Silverlight Tech Preview!

Jenny — Wed, 24 Feb 2010 14:29:00 GMT

The Silverlight development team has been hard at work creating our Silverlight datagrid, and I thought that I would let you in on our progress and give you a glimpse as to what you can expect when it's released. Last year at PDC 2009, we demoed what was an early-stage version of the grid. Since then, it has come a long way and is nearing feature completion.

Xceed DataGrid for Silverlight takes user experience to a whole other level. Perfectly smooth horizontal and vertical scrolling, fully animated column reordering and resizing, customizable animations for group expansion and collapse, as well as transition animations for when rows are added or removed, provides an unprecedented level of UI slickness and responsiveness.

Asynchronous data virtualization. THE must-have in a Silverlight data grid, it’s the cornerstone on which Xceed DataGrid for Silverlight is built. We’ve packed a lot into our implementation of this, such as major advancements in how virtualized data is handled, automatic discovery, active pre-fetching and caching of data, quick navigation, and instant grouping. You can add to that built-in support for WCF Data Services and WCF RIA Services, as well as "event-driven" and "full-list" data sources (i.e., pass-through data virtualization) and many more to come, which means that where you get your data from no longer matters. Just connect to the source, and we handle the rest. Simple. Trust me: you haven't seen anything like this in any other grid before.

Sometimes, appearances are everything. Don't like the yellow/orange/i-am-sorry-Catherine-i-do-not-know-the-exact-color border in the PDC-demo theme? Change it! Xceed DataGrid for Silverlight is 100% "blendable" and its elements can be customized to match the look and feel of any application. Or if you prefer, you can use one of the built-in themes that were designed for the grid with user experience in mind.

Now, I know the first question our current WPF clients will have is this: "I have a project that currently uses Xceed DataGrid for WPF. Can I just switch it out for the Silverlight version?" The answer to that is no, you can't. Why? Well there are a couple of reasons. First, Silverlight is not WPF; there are things you can do in WPF that you can't do in Silverlight. Doing a direct API port would have been 1) nearly impossible and 2) would not have allowed us to take full advantage of the Silverlight platform. Second, since the initial release of Xceed DataGrid for WPF, we have developed new, innovative ways of handling data, but it would be impossible to implement them in that product without doing major breaking changes. With our upcoming Silverlight datagrid, we have been able to implement these new techniques without worrying about backwards compatibility. At any rate, although it is not a direct API port, the API will feel very familiar and you should feel right at home using the Silverlight datagrid. We intend to also provide a WPF-compiled version of the Silverlight grid, so if you want to build for both platforms, you will have the option to do so with the Silverlight datagrid.

Want a quick point-by-point list of the features/goodies that we are aiming for? Here you go:

Ultra smooth and responsive tabular layout
Multi-level grouping
Sorting
Filtering
Sticky group containers
Animated vertical and horizontal scrolling
Fixed and scrollable headers and footers
Easy group navigation (think something similar to the group-navigation control in Xceed DataGrid for WPF)
Animated column reordering and resizing
Row and cell selection

Data Virtualization

Asynchronous data loading for continuously responsive UI
Minimal (if at all) code required
No discovery needed on remote data source
Pre-fetching and caching of data
Instant expanding and collapsing of groups
Quick navigation through data source
Support for almost any type of data source including WCF Data Services and WCF RIA Services

Editing

Default editors for all the common data types
Ability to create custom cell editor controls
Validation (e.g., IDataErrorInfo, INotifyDataErrorInfo)

While you wait for the official launch of Xceed DataGrid for Silverlight, I will (hopefully) be blogging about specific features and how easily they can be used in any Silverlight application. I will also take you on indepth tours of some of the design concepts behind our latest baby

In order to get feedback from the community, we will be opening a private beta in March to make sure that we have the best possible product when it is officially released. If you are interested, send me an email to datagridbeta@xceed.com letting me know the type of project in which Xceed DataGrid for Silverlight would be used (e.g., new project, moving existing WPF project to Silverlight, replacing an existing grid) and the timeframe needed to make a decision, and I will sign you up for the beta.

Questions, comments, feature requests? Now's the time!

Xceed Professional Themes for WPF - 2 New Themes!

Matt — Fri, 19 Feb 2010 20:39:00 GMT

The upcoming release of Xceed Professional Themes for WPF will be our biggest update to the product since it was released last year. The latest incarnation of Xceed DataGrid for WPF brought a Windows 7 inspired theme as well as the Live Explorer theme to the table. Both these themes will now be available in the next version of Xceed Professional Themes for WPF.

So let's talk about the Live Explorer theme. When we first created our Xceed DataGrid for WPF Live Explorer we wanted to have a branded theme that would demonstrate how much of our product you could "re-style". At the time we didn't offer it as an available theme since we thought it would be too specific to our application. Boy, did we guess wrong on that one! Many of you responded very well to the theme and some of you were furious at us for not making it available. We heard you! Here's what it's going to look like :

The Live Explorer theme was crafted so you can easily add it to your window and instantly get the look we are using in our own Live Explorer. It is perfect for applications that require a "darker" environment with a hint of color to keep it visually pleasing. Keep in mind that the video displays a work-in-progress version of the theme but very little should change visually when it is released. We also decided to expose an additional style for the toolbar to make it orange instead of gray.

The second theme we added is a Windows 7 inspired theme. Windows 7 creates a very colorful and exciting environment and we wanted to capture this and bring it to our products. We tried to bring a more extravagant experience with this theme and hopefully it will allow you to build a fun application around it.

Both these themes are available in Xceed DataGrid for WPF and the upcoming version of Xceed Professional Themes for WPF. Another version of Xceed Professional Themes for WPF will provide styles for Microsoft's datagrid and calendar controls should come out shortly after.

If you have any questions about the product, feel free to contact us!

Ode to the Hidden and Forgotten

Jenny — Fri, 22 Jan 2010 17:41:00 GMT

Ever since I started working in Silverlight, I found some strange ommissions, whether voluntary or not, in the Silverlight API. At times, this was very frustrating since I was expecting something as common as BindingList to be there. So, to end this week on a more "creative" note, I present you with an ode. Enjoy!

Ode to the Hidden and Forgotten

My head aches as I search for something new,
Something to replace all the things they do.
Yet Silverlight keeps thwarting all my plans,
By hiding classes that I want to use.

No longer can I batch initialize.
Oh, where is ISupportInitialize?
Why has IBindingList been abandoned?
I don't want ObservableCollection!

Why do you stop me from selecting styles?
Is StyleSelector never to return?
Triggers! Oh, dear Triggers! Where have you gone?
Without you, I will have to manage states.

And to all the others that are hidden,
And to those that were simply forgotten:
We will remember you and all you do,
When we must search for something new to use.

Sneak Peek at Version 3.6!

Jenny — Mon, 18 Jan 2010 18:44:00 GMT

So I didn't get much feedback from my post asking for help in regards to what to write, so I will go with the only suggestion I received and let you in on the upcoming features planned for the next major version of Xceed DataGrid for WPF.

So let's start with a feature that clients have been asking for since the virtualizing collection view was released: multiple selection! Yes ladies and gentlemen you will finally be able to select more than one row when using a virtualized source! Actually, the whole selection process is being revamped, so expect to see some (long awaited) changes including.... wait for it.... CELL SELECTION!

Performance! As if the grid was not already fast enough, get ready to see some performance enhancements in the standard table view!

Finally, after many many requests, the Live Explorer theme, which can be seen in the the Xceed DataGrid for WPF Live Explorer, is now included with Xceed DataGrid for WPF! Want more? How about a beautiful new Windows 7 theme? (I feel like I am on an infomercial!).

Another fantastic new addition is the print preview, which will allow users to take a look at their snazzy documents before sending them to the printer.

QTP? Did someone say QTP? You heard right! The upcoming edition of Xceed DataGrid for WPF will provide full QTP support!

Last, but definitely not least since I am most likely forgetting some, is the new group-navigation control, which replaces the previous group-navigation button, and provides quick and easy navigation between groups.

So which features are part of the Standard Edition and which ones are part of the Professional Edition? Glad you asked! Here's the breakdown:

Professional Edition Features

Windows 7 and Xceed Live Explorer themes
Print Preview
Multiple selection when using data virtualization
Group-navigation control
QTP support

Standard Edition Features

Improved performance in table view
Cell selection
Customizable cursors in most views

Of course, you can always check out our feature comparaison chart for the full list

Enjoy!

My Search for My Perfect Twitter Client

Jenny — Tue, 12 Jan 2010 16:00:00 GMT

Hello, my name is Jenny (@_random_) and I am a Twitter addict. Okay, not really and nothing even close to @kosmatos, but close enough that I check Twitter many times a day at work and on my iPhone to see what is going on. I don't follow many people and not many people follow me, but I like the interactions I have with those people and sometimes good conversations and suggestions come up. Sometimes I just write random stuff because I am bored. But I guess that if there is a point to Twitter, that is it.

So, ever since I have come back from the PDC, I have been using the Seesmic desktop client for Twitter, and although not perfect, it seemed to "do the job" although something was annoying me about it and yesterday I figured out what it was: the scrolling! When I scroll, I don't want to have to spend a few seconds finding the last tweet I was reading. It's annoying and it breaks the "flow". And so began my search for the perfect Twitter client this morning.

Now, if you are expecting an indepth review of Twitter clients, you are reading the wrong blog post. I didn't go looking for THE best Twitter client. I went looking for the best one for ME. So what was I looking for? I had no idea, but I figured I would know it when I saw it. So the first client I installed after uninstalling Seesmic was Tweetdeck, which many people at Xceed seem to enjoy using so I figured that it was probably a safe bet. A couple of minutes later, I was up and running with Tweetdeck and a couple of minutes later it was unistalled. Yes, it scrolled better than Seesmic but I found it hard to differentiate between my tweets, those that are replies to my tweets, and all the other noise. I really hate the new "Blend" themes (if that's what they are called). Use color people!! Black, white, and multiple shades of gray are not the best colors to use when you need to differentiate things. If you insist on using them, at least give me the option to change or customize them to something that I will like. Yes, I know this is a matter of opinion, but I told you I was looking for the perfect Twitter client for ME, not for YOU (I'm talking to you @superdupercat! )!

While on Tweetdeck, @ftdube sent me a tweet telling me to try Digsby, so I did. As soon as Tweedeck was uninstalled, I downloaded and installed Digsby. I would like to say that I actually tried it; however, when I attempted to add my MSN account in addition to my Twitter account (hey, it's also an IM client) it said my password was "too long". Excuse me? My password is too long? Ummm. No. I didn't even try it as a Twitter client. If it can't handle 24+ character passwords, it has no business being client for anything.

After my failed Digsby attempt, I took a look at the Twitter web interface to see what clients people were sending from. I saw many Tweetdecks and some Seesmic, but other than that it seemed to be all iPhone apps. "iPhone apps!! Maybe Twitterrific is available for Windows" I thought to myself. So off to the Twitterrific website I go only to be disappointed that there is no Windows version available. I love Twitterrific on my iPhone. It just works and it's easy to find/see what I am looking for. But alas, I was to be disappointed one more time.

At this point I am getting frustrated and thinking about going back to Seesmic since the only thing that actually bugged me was the scrolling. After quick consideration I decided to go back to the Twitter web site to see if they had a list of clients that they recommended. Lo and behold, right beside the listing for Twitterific was Twhirl. I had seen some tweets that originated from Twhirl before so I decided to try it out. Why? Honestly, because it looked pretty in the screenshot. No black/white/gray theme. 45 minutes later, I am still using it.

So what was I looking for? I think in the end it came out to "easy". I want it to be easy. I want to easily see what I tweeted, who replied, and whatnot without having to really think about it. The fact that it can stay on top of other windows (with or without opacity) and also that fact that it has a built-in spell checker just made it that much better for ME.

So that's it. My search for my "Perfect Twitter Client" has come to an end. For now

Xceed Consulting Wins on WPF gig

Odi [Xceed] — Fri, 11 Dec 2009 15:12:00 GMT

A few months back, Lee Sherry, Senior BI Manager at Microsoft Business Intelligence, contacted our sales director, Charles, about having an app created for the company. Charles understood right away what her needs were and proposed the project to Pierre-Luc (“PL” for short!), Lead Developer for Xceed DataGrid for WPF. Everyone involved with the project knew that the star of the app, our WPF datagrid, would make it easy to deliver the goods in short time!

What Lee wanted was a rich, cutting-edge XAML Browser Application that would let the company’s managers navigate easily through numerous selected reports, filtering, sorting, and grouping their data. But the application had to remain responsive at all times, and Lee wanted an all-purpose solution, one that avoided hard-coded, pre-defined views, which would have limited the flexibility of the application. She also emphasized that it had to work with their existing data structure.

Xceed’s developers met this challenge head on and devised a solution that was a stream-lined XBAP that interfaced with a SQL data source, which ran in Partial Trust. By doing things this way, the less technically savvy users of the software didn’t need to install certificates on their machines. However, this architecture meant using a Windows Communication Foundation (WCF) Web service, which acted as an intermediary between the XBAP and the SQL server. A data paging system was also implemented to fetch the data through the Web service. Of course, our designer team played a big part in the process, creating a gorgeous and compelling user experience!

The application was developed entirely by Xceed, and met Lee’s expectations fully, helping Microsoft reach its objectives and saving the company time and money. After receiving the app, Lee e-mailed the following to Charles: “The Xceed WPF grids allowed us to deliver some fantastic interactive tools to our executives and increase the impact of our information. We are extremely satisfied with the professional support by the entire Xceed team. The Xceed technology is visually striking and works beautifully with our Silverlight and WPF infrastructure.”

Getting Ready for PDC 2009!

Jenny — Wed, 28 Oct 2009 13:31:00 GMT

For the second year in a row Xceed will be exhibiting and attending at PDC 2009! In addition to the amazing new features in the upcoming version of Xceed DataGrid for WPF, we will be demoing the latest development build of our future Silverlight grid.

This year we will be handing out snazy Xceed t-shirts and if you get spotted wearing one, you will be entered into 1 of the 3 draws to win a 16GB Zune HD video and MP3 player!

So if you want to come see what we've been working on, ask questions, make suggests for future releases, or simply chat with some of our team members make sure you stop by our booth! Also make sure you stop by Party with Palermo! We will be fresh off the plane but ready to party!

See you in LA!

Writer's Block

Jenny — Thu, 24 Sep 2009 14:49:00 GMT

When we started writing blogs at Xceed, I think we all thought that we would always have interesting content to post about and that we could never run out of ideas. How wrong we were! For me, what I find the hardest is finding topics that will interest our current and future clients and that interest me as well! So here I am , more than a month since my last blog post and I have no ideas what to write about.

Now, this is where you come in! Tell me what you would like me to write about! Do you want to know more about a specific feature? About upcoming features? About developement at Xceed? A short story about kittens and unicorns? Something about me? About one of the developers?

Help!!

Sneak Peek at Version 3.5!

Jenny — Wed, 12 Aug 2009 14:21:00 GMT

Yes! Even with version 3.2 just out the door, the developers at Xceed have been hard at work on version 3.3, now officially version 3.5. So, what new features are being introduced in the latest version? I'm glad you asked! Among other features, the long awaited "smooth-scrolling table view" finally makes its debut in version 3.5. Known as the Tableflow view, this new view provides smooth, animated scrolling and column reordering as well as "sticky" group, grid, and detail headers and footers, which remain at the top and bottom of the grid until the next group or detail needs to be displayed. The "group-navigation" button, which is displayed in the group headers, can be clicked to have the first item in the group brought to the top of the viewport. Take a look!

So what do you need to do to replace the classic Table view you have been using with the Tableflow view? Simple! Search and replace "TableView" with "TableflowView" and you're done!

In addition to the Tableflow view, support for 2 new filter criteria has been added to the filter row: "starts with" and "ends width", which allow the content of a column to be filtered according to the values that start or end with the specified filter value.

Another nice little feature that was added in version 3.5 is a notification glyph that is displayed when the grid is bound to a virtualizing collection view. This glyph (actually, it's 3 separate glyphs) are displayed when data is loaded into the grid, when data is being committed, and when there is an error. In the demo below, you can see the default glyph that is displayed when data is being loaded. Now, if you don't like the default connection-state glyphs, you can always replace them with the image of a kitten! Everyone likes kittens

Quick usage preview of Xceed Professional Themes for WPF

Matt — Thu, 23 Jul 2009 18:29:00 GMT

I thought it would be a good idea to share with you how easy you'll be able to integrate our new Xceed Professional Themes for WPF product into your application. Version 1.0 will include 5 different themes: Media, Glass, and Office 2007 Black/Blue/Silver. Future versions will probably include Office 2010, Windows 7 themes, etc. You can expect each theme to have a version for Xceed DataGrid for WPF as well. This way, you can keep the datagrid's look in sync with all the standard controls.

Once you have the product installed, the first thing you'll want to do is add references to your project. Each theme has an assembly associated with it. For this example, we'll work with the Media theme (similar to the WMP11 theme in Xceed DataGrid for WPf). Once you have added the reference, you'll want to set the namespace declaration in XAML:

xmlns:xcpt="http://schemas.xceed.com/wpf/xaml/themes"

xcpt stands for Xceed Professional Themes . We wanted to preserve the proper "WPF" way as much as possible, so each theme is basically a resource dictionary that you can add to your resources. You can simply add the resource dictionary as a resource to your entire window:

<Window.Resources>
<xcpt:MediaResourceDictionary/>
</Window.Resources>

This will also work if you want it to be applied to your entire application.

<Application.Resources>
<xcpt:MediaResourceDictionary/>
</Application.Resources>

You're almost ready to go. You need to first take care of the licensing. Our custom resource dictionary exposes a LicenseKey property:

<xcpt:MediaResourceDictionary LicenseKey="Your-License-Key-Here"/>

If you are in trial mode, you should be able to find your trial license key in the Resource Center installed with the product. If you have purchased the product already, you will find your license key in an email sent by our sales department. If you are trying the theme on an already existing application, you can hit F5 and see your standard controls styled with the Media theme. Simple enough?

The method I just described is using all our resources implicitly, meaning that you did not have to define explicitly on each controls which theme you want to use. If, for any reason, you do not wish our themes to override all your defined styles, you can use this product explicitly.

<xcpt:MediaResourceDictionary StyleUsageMode="Explicit"/>

As you already probably guessed, the default value is Implicit. Now that you have changed the StyleUsageMode property, if you hit F5, you should not see any difference from what you usually see without the themes referenced.

This means, however, that you will have to define the resource you want for each control. Let’s take a button for example:

You have to force the Style of the Media button on the desired control. You will find a complete list of keys for our controls available in our documentation if you chose to work in Explicit mode.

When creating this product, we were also aware that even though we styled all the standard Microsoft controls, some users would require us to go further. This is why in our light API we added some brush resources that you can apply to your own controls. Here's an example:

This way, you create your own controls using some of our resources. As demonstrated above, you can set Background and BorderBrush to any element using our resources. A complete list of exposed resources will be available in our documentation as well. Of course, there's always the option to get our Blueprint Edition to get access to the complete XAML resources for all controls.

Finally, a request I have received a few times and even in my previous blog post is to be able to change themes on the fly for your application. Basically, something to allow the user to have a Combobox with a list of available themes that can be changed during run-time. Here's a quick and dirty way you can do this, by defining your Combobox:

In your codebehind you will have to add the ThemeComboBox_SelectionChanged method, which should look like this:

private void ThemeComboBox_SelectionChanged(object sender,
SelectionChangedEventArgs e)
    {
      if (e.AddedItems.Count > 0)
      {
        this.Resources = ((ComboBoxItem)e.AddedItems[0]).Tag as
ResourceDictionary;

}
}

So this pretty much covers how our new product called Xceed Professional Themes for WPF will work. If you have questions about licensing and pricing, you can already contact sales@xceedsoft.com. You can expect this product to be available by mid/end of August. Enjoy!

A Glimpse at Xceed Professional Theme Packs for WPF.

Matt — Thu, 25 Jun 2009 16:47:00 GMT

For the past few months, Catherine and I have been working on a new product called Xceed Professional Theme Packs for WPF. This product will include all Standard Microsoft controls : Button, RadioButton, Checkbox, ListBox, TreeView, Toolbar, StatusBar etc... and about 30 different controls—all skinned.

The main reason why we decided to develop this product is because of you, our users. We received many comments like : "the WMP11 theme is nice for the DataGrid; however, the rest of my application doesn't fit!". It seemed like the next logical step was to offer a product that would enable our users to give their application a uniformed look. This product does not have a dependancy on Xceed DataGrid for WPF since we can easily imagine users wanting to use this product in any WPF application.

One of the features this product will have is the ability to skin all your controls and still respond to visual properties. For example, having a WMP11 button will completely redo the look of the button; however, we were careful to still support properties like Background and BorderBrush, for example. If you look a the following image, you'll see three different buttons all with the same skin. The only difference between each button is the Background property :

We wanted to enable our users to modify the look of the controls without compromising the skin. To achieve this, we had to exploit TemplateBindings as much as we could. TemplateBindings in a template allow you to chose which VisualElement in your VisualTree will respond to a given property. So in our WMP11 Button template, we added a layer over the gradient brush that gives the WMP11 look. So :

<Rectangle Fill={TemplateBinding Background}

Opacity="0.3"/>

This is obviously not exactly how our template looks, it's just to give you an idea of how we proceeded. The Rectangle that has the opacity set to 0.3 is the one that is template bound to the background property. This will allow our users to set a color to the control without overriding the grandients as seen in the image.

Here's a quick video demonstrating some of our controls in action :

Not all controls are being displayed but it should give you a general idea of where we're going with this product. One of the toolbars has its background property set to DeepSkyBlue and, as you can see, it still fits with the look of the control.

I'm pretty excited about Xceed getting this product out to you as soon as possible. We are currently in a final polishing phase and hoping for this to be released by the end of the summer. Expect to see 5 different themes with over 30 controls including : Office 2007 Blue, Black and Silver, WMP11, and Glass. Have questions about the control? Feel free to email me at drimonakosm@xceed.com or follow me on twitter at www.twitter.com/mattd1980.

Overview of the new v3.2 datagrid for WPF

Odi [Xceed] — Mon, 15 Jun 2009 13:43:00 GMT

Today marks the release of v3.2 of Xceed DataGrid for WPF. This is the 9th major update since the product was first introduced 2.5 years ago. Another one is coming, hot on its heels for August, with smooth scrolling innovations and other UI improvements, but here's what's new in today's release.

- There are now two paid editions of the DatagGrid, the new Standard Edition, and the existing Professional Edition.

- The new Standard Edition is aimed at folks who don’t need a whole lot of advanced features, but would still like to save time and get better results than when using Microsoft’s upcoming datagrid for WPF. The time saved, from the more complete design, abundant data binding options, documentation and helpful Xceed staff should easily outweigh its affordable $300 cost. It also has more features than the Microsoft grid, such as rich grouping support, more cell editors and input validation. Best of all, there’s a built-in instant upgrade path, so if your users eventually want filtering, printing, exporting, field chooser or other features, you can just upgrade and turn those capabilities on, instead of being painted in a corner with a control not designed to do them.

So what’s new in v3.2? For this release, we’ve made getting to your data, and presenting it properly, a lot easier to do.

- First, the datagrid now autodetects foreign keys in your datatables, so now it is easier than ever to display the corresponding values you want to display, instead of IDs. It also works with enumerations. To activate this new feature, just set AutoCreateForeignKeyConfig to True.

- Next, we added support for custom key value mappings. This makes it easy to map any kind of values or objects to fields in your data that represent keys. For example, if your table of employees has an Employee ID integer field representing an employee object, you can easily map that field so that the datagrid uses corresponding employee’s First name and Last name fields formatted as “Last name, First name” as the value to be displayed instead of the integer.

- Next, for users of the powerful Data Virtualization feature – which in v3.2 now also supports grouping – if your data source implements IQueriable, and LINQ does, we’ve made providing data to the datagrid a snap. You no longer have to handle a bunch of events to provide the datagrid with data, and you no longer have to worry about how the datagrid is sorted or grouped. Doing so was tiresome, now it’s code free.

- We also completed full support for the Entity Framework, which makes it super easy for Entity Framework users to get the grid to display hierarchical data. When binding the datagrid to a list of Entity objects, the datagrid will now automatically find and load the detail data into subgrids and use master/detail view. To turn this on, set AutoCreateDetailsDescription to True on the DataGridColectionViewSource and AutoCreateDetailConfigurations to True on the datagrid.

- We’ve also made it easier to work with unbound columns, in two ways. First, we support unbound data, which appends data to business objects that the grid displays. This method is great for displaying calculated columns or anything else which depends on the data. Second, we now directly support unbound columns, for displaying static information, such as a delete button for every row, progress bars, or any other controls or content which don’t depend on data.

The other important updates in this release deal with filtering. In previous versions, we offered Excel-like auto filtering, which provides a button for each column so that users can filter in the same way Excel does. In this version, there are two important additions to filtering capabilities for end users.

- First, we’ve added the ability for developers to define their own custom distinct values to add to the AutoFilter drop-down. You can use this to make the auto-filtering choices a lot more useful for end-users. For example, on a column with dates, you can offer the choice to filter by month. For names, the filtering choices could now be “A-C”, “D-F”, and so on. For numbers, you could group them into appropriate ranges, such as “0-99”,”99-1000” or “Odd numbers” and “Even numbers” – anything you want.

- Next, we’ve added a new row type, called the Filter Row. This row can be placed in the grid’s fixed or scrolling headers or footers, and provides users with an alternate way to set and view the datagrid’s current filter settings. It’s always visible, and works great with date ranges, as you can set a start and end date to filter by, or set value ranges such as “>5 AND <10”. You can filter Booleans using a three state checkbox, and strings can be filtered by typing a value that is contained in the string.

One last thing. The datagrid is now compiled for .NET 3.5 SP1. This service pack has been available for some time, and according to Microsoft, should be automatically pushed out and installed everywhere through Windows Update around the November timeframe.

Thanks, and I can’t wait to show you the a video of what’s in the next release, a release that’s coming soon, and has lots of amazingly responsive smooth scrolling and animation.

Let us know what else you want us to implement, by posting in the Roadmap 2009 thread on the forums at Xceed.com.

Good programming!

Sneak Peek at Version 3.2!

Jenny — Mon, 01 Jun 2009 14:38:00 GMT

So version 3.2 is compiled and ready to be released in mid-June! It has been a hectic past couple of weeks trying to get everything done and we are all very happy with the end result. I know that many of you have been anxiously waiting for the 3.2 release so I though I would give you a little preview to whet your appetite. So what exactly is included in version 3.2? Good question! It looks something like this:

Custom distinct values (e.g., "less than 10") in the auto-filter control
Filter row that allows end users to provide filter criteria at run time.
Built-in support for Entity Framework
Improvements to the datagrid's data virtualization capabilities including grouping and support for data sources implementing IQueryable (LINQ)
Automatic detection of foreign key constraints and enumerations
Support for unbound columns and data
Enable and disable grouping and sorting on a per-column basis
and a couple little extras that you will discover!

One feature that clients have often inquired about is custom distinct values. Or, in other words, being able to provide "Excel-like" filter criteria such as "less than x" and "greater than x" in the auto-filter drop down. With version 3.2, it is possible to do so and even more. How? Easy! Just use the QueryDistinctValue event exposed by each DataGridItemProperty and return the desired distinct value. For example, in the code below, I provide distinct values that will filter date/time values according to the year (by default, all dates would have been displayed in the auto-filter control) and I also provide value ranges where, by default, all values would have been displayed in the drop down.

private void DataGridItemProperty_QueryDistinctValue_Date( object sender, QueryDistinctValueEventArgs e)
{
if( e.DataSourceValue is DateTime )
{
e.DistinctValue = ( ( DateTime )e.DataSourceValue ).ToString( "MMMM" );
}
}

private void DataGridItemProperty_QueryDistinctValue_Range(object sender,QueryDistinctValueEventArgs e)
{
if( e.DataSourceValue is decimal )
{
   decimal value = ( decimal )e.DataSourceValue;
   if( value <= 100 )
   {
     e.DistinctValue = "0 - 100";
   }
   else if( value > 100 && value <= 500 )
   {
     e.DistinctValue = "101 - 500";
   }
   else
   {
     e.DistinctValue = "500+";
   }
}
}

Beautifully simple

Version 3.2 also adds the ability for end users to provide filtering criteria at run time through the use of a "filter row", which can be added to the fixed or scrolling header and footer sections of a grid, group, or detail. In addition to supporting relation filters such as "contains", "equal to", and "greater than", among others, the filter row also supports conditional filters such as "AND" and "NOT", which allow a column to be filtered by more than one filter criterion.

Another sought-after feature is built-in support for Entity Framework. Although it was possible to use Entity Framework with the previous version of the grid, version 3.2 makes this a whole lot simpler by automatically detecting Entity collections (EntityCollection<TEntity>) and displaying their content as details. In the case where the reference to related Entity objects are not loaded, the QueryDetails event, exposed by the EntityDetailDescription class, can be handled to provide details for a data item. For example, in the code snippet below, a query that will return the appropriate details for a parent item is executed and the Handled property set to true to indicate that the event was handled.

private void EntityDetailDescription_QueryDetails( object sender, QueryEntityDetailsEventArgs e )
{
Customer customer = ( Customer )e.ParentItem;

    // Since EntityFramework doesn't load automatically references to
   // other objects, we build a query that will include those objects.
  // We start from the base query but we could have added restrictions
    // to the query.
   ObjectQuery<Order> query = customer.Orders.CreateSourceQuery();
   customer.Orders.Attach( query.Include( "Employee" ).Include( "Shipper" ) );
   e.Handled = true;
}

A feature that was lacking in the 3.1 implementation of data virtualization was grouping support. With version 3.2, this limitation is a thing of the past :) Now, unlike the other features I just mentioned, grouping in a virtualized collection view is not something for the feint of heart! But, if you know what data you are dealing with and with the help of the Data Virtualization sample, which provides a detailed example of how to implement grouping support, you should be up and grouping in no time. If not, contact our support department, that's what they are there for

For those of you who are already using the virtualized collection view provided with Xceed DataGrid for WPF, you may be happy to learn that version 3.2 also provides built-in support for IQueryable data sources through the DataGridVirtualizingQueryableCollectionView and its XAML-proxy the DataGridVirtualizingQueryableCollectionViewSource, which, by the way, earned its developer the "longest class name" award!

A feature that has been implemented in version 3.2 whose lack caused a lot of frustration in previous versions, is automatic detection and support for foreign keys and enumerations. In previous versions, in order to display foreign key constraints, you had to write a lot of code, which, quite honestly, was time consuming and annoying to implement. In version 3.2, all that is a thing of the past (although you can still use your code if you want!). By default, foreign key constraints defined by a DataTable or DataView used as a data source, as well as enums, can be automatically detected and displayed and edited, through a ComboBox, as the corresponding value rather than its key. If you are dealing with a different type of source or would like to provide custom key/value mappings, you can do that too. Although it is recommended to always bind the grid to its data by-proxy of a DataGridCollectionView[Source] or any other data-grid collection view, it is not obligatory. When binding a grid directly to a source that contains foreign key constraints or enums and data-grid collection view is not used, it is still possible to display the value rather than the key of the constraints and enums; however, they must be defined manually by providing the appropriate foreign key configurations, and a ForeignKeyConverter must be used in order to convert keys to values and back (see ReportsTo column in Example ).

</Grid.Resources>

<xcdg:DataGridControl x:Name="PersonsGrid"
ItemsSource="{Binding Source={x:Static Application.Current}, Path=Persons}">

    <xcdg:DataGridControl.Columns>
       <xcdg:Column FieldName="Occupation">
          <xcdg:Column.CellContentTemplate>
             <DataTemplate>
                <TextBlock Text="{Binding Converter={StaticResource occupationToStringConverter}}" />
             </DataTemplate>
          </xcdg:Column.CellContentTemplate>
          <xcdg:Column.ForeignKeyConfiguration>
            <xcdg:ForeignKeyConfiguration ItemsSource="{Binding Source={StaticResource occupationValues}}"/>
          </xcdg:Column.ForeignKeyConfiguration>
       </xcdg:Column>
       <xcdg:Column FieldName="ReportsTo">
          <xcdg:Column.CellContentTemplate>
             <DataTemplate>
                <StackPanel Orientation="Horizontal">
                   <TextBlock Text="{Binding FirstName}" />
                   <TextBlock Text=" " />
                   <TextBlock Text="{Binding LastName}" />
                </StackPanel>
             </DataTemplate>
          </xcdg:Column.CellContentTemplate>
          <xcdg:Column.ForeignKeyConfiguration>
            <xcdg:ForeignKeyConfiguration ItemsSource="{Binding Source={x:Static Application.Current}, Path=Persons}"
                                           ForeignKeyConverter="{StaticResource personForeignKeyConverter}"
                                           ValuePath="PersonID"/>
          </xcdg:Column.ForeignKeyConfiguration>
       </xcdg:Column>
    </xcdg:DataGridControl.Columns>
</xcdg:DataGridControl>
</Grid>

Another feature that was often requested is support for unbound columns and data. Now, you may be wondering why I am referring to unbound columns AND unbound data. Good question. Initially, this feature was known as unbound columns; however, after it was implemented, we realized that unbound columns and unbound data were two different things. Let me try to explain... "Unbound data" is data that can be "appended" to a data item through the use of unbound item properties, which are represented by the DataGridUnboundItemProperty class. Unlike "unbound columns", which can be used to display non-data related information such as a label or controls that allow some sort of action to be carried out, unbound item properties can be used to provide additional data, such as calculated columns. If you are scratching your head at this point, don't worry, it is a lot simpler than it seems! Let me demonstrate:

Unbound Data

<xcdg:DataGridCollectionViewSource.ItemProperties>

          <xcdg:DataGridUnboundItemProperty Name="TotalUnitsValue"
                                            DataType="{x:Type sys:Double}"
                                            QueryValue="DataGridUnboundItemProperty_QueryValue" />
        </xcdg:DataGridCollectionViewSource.ItemProperties>
     </xcdg:DataGridCollectionViewSource>

<local:CurrencyConverter x:Key="currencyConverter" />

</Grid.Resources>
<xcdg:DataGridControl x:Name="OrdersGrid"
                        ItemsSource="{Binding Source={StaticResource cvs_products}}">
     <xcdg:DataGridControl.Columns>
        <xcdg:Column FieldName="TotalUnitsValue"
                     Title="Total Inventory">
           <xcdg:Column.CellContentTemplate>
              <DataTemplate>
                 <TextBlock Text="{Binding Converter={StaticResource currencyConverter}}" />
              </DataTemplate>
           </xcdg:Column.CellContentTemplate>
        </xcdg:Column>

        <xcdg:Column FieldName="Photo"
                     Visible="False" />
     </xcdg:DataGridControl.Columns>
</xcdg:DataGridControl>
</Grid>

private void DataGridUnboundItemProperty_QueryValue( object sender, DataGridItemPropertyQueryValueEventArgs e )
{
System.Data.DataRowView row = e.Item as System.Data.DataRowView;
if( row != null )
{
   if( row[ "UnitsInStock" ] != DBNull.Value )
   {
     e.Value = ( double )( ( short )row[ "UnitsInStock" ] * ( decimal )row[ "UnitPrice" ] );
   }
}
}

Unbound Columns

</Grid.Resources>
<xcdg:DataGridControl x:Name="OrdersGrid"
ItemsSource="{Binding Source={StaticResource cvs_products}}">
<xcdg:DataGridControl.Columns>

       <xcdg:UnboundColumn FieldName="EditRowColumn"
                           Width="30"
                           MinWidth="30"
                           MaxWidth="30">
          <xcdg:UnboundColumn.CellContentTemplate>
             <DataTemplate>
                <Button Click="Button_Click"
                        Content="..." />
             </DataTemplate>
          </xcdg:UnboundColumn.CellContentTemplate>
       </xcdg:UnboundColumn>
        <xcdg:Column FieldName="Photo"
                     Visible="False" />
     </xcdg:DataGridControl.Columns>
</xcdg:DataGridControl>
</Grid>

private void Button_Click( object sender, RoutedEventArgs e )
{
Cell cell = Cell.FindFromChild( sender as DependencyObject );

ProductsEditorWindow editor = new ProductsEditorWindow( DataGridControl.GetParentDataGridControl( cell ).GetItemFromContainer( cell.ParentRow ) as DataRowView );

editor.ShowDialog();
}

Notice that although both the UnboundColumn and DataGridUnboundItemProperty classes both use the term "unbound" they are not meant to be used together. Meaning that an unbound item property's corresponding column is a Column and not an Unbound column.

A little feature, but one that has been often requested, is to enable and disable grouping and sorting on a per-column basis. If you are one of those who requested this feature, version 3.2 is what you need!

So there you go! Version 3.2 is scheduled to be released on June 15th. So mark the date on your calendar!

Any questions or comments? Feel free to post them in the comments section below.

Don't sacrifice function for looks!

Matt — Fri, 29 May 2009 15:13:00 GMT

This is somewhat related to my previous post about "less is more". Another thing that I've noticed over the years is that some websites or applications tend to give a priority to looks over function. There are some exceptions to this that obviously depend on the theme of the application or website. Now, WPF and Silverlight provide us with a lot of features to alter the visual appearance of an application and as I mentionned before: with great power comes great responsibility.

A lot of our clients have to wear the designer, artist, and programmer hat all at once. Not everyone has the chance to have an integrator and artist/designer working alongside. If you are just starting out in WPF or Silveright and do not have a lot of experience in design my first advice is this: don’t try to be cute. Design is hard and requires a lot of experience, you wouldn’t expect someone to start coding in C# and or VB.NET by improvising, well don’t expect you can easily improvise design ;-).

When I say “don’t sacrifice function over looks” it means elements placed on your application or website that require interaction should not be blended in your design in a way that they cannot be easily accessible. This might sound very basic; however, even the most advanced design companies make these fundamental mistakes. For example, here’s something Odi (@kosmatos) tweeted : “So who can tell which is currently selected in the "Public | Private" TOGGLE button? How do you know? http://twitpic.com/659sb”. And he’s right, the purpose of a ToggleButton is to easily determine if a button is currently toggled or not. When designing an application make sure your controls are easily accessible and that their visual representation respects the essence of the controls.

Another fundamental way to allow users to easily indentify an element that can be manipulated is by using contrasts. Make sure that what is important to the end users visually stands out. This is another point that may sound very basic to most of you; however, it is a detail that can be forgotten or ignored. Here’s a selected menu item from a very awesome website I visit:

Bright orange on white is not the best way to make text stand out. Test your contrasts and make sure that important text or informationcan be easily read.

Regroup valuable information or sections currently important to the user. We faced this issue when developing our Resource Center. We wanted to display a lot of information in a single form. For those who don’t know what the Resource Center looks like, here it is:

We have a main section in our circular listbox, we have News Headlines and Licensing Information. That’s a lot of content to throw at our users. So we have to guide our user eyes to what is important. The currently active section will have a big icon standout and the icon will be linked to the currently active section, in this case Getting Started, which is represented by a timer. One of the issues we had is that the news headline would have grabbed the user's attention too much when really this is not where we want them to initially look. So what we did is we made the text semi transparent until the user hovers over the section. We also decided to hide our scrollbar on the News section that would just be cumbersome to the user's eye. So with this, we hope that the users initially pay attention to the middle circular panel.

This is just some advice I’ve learned by working with our designer over the years. They are fundamental principles that we obviously did not invent. Those are related to the Contrast, Repitetion, Alignment, Proximity (C.R.A.P.) design principles brought up by Robin Williams in his popular book The Non-Designer’s Design Book. You can do a quick google search for C.R.A.P. Web Design to find more information about this. Keep in mind that the C.R.A.P. Principles applies, in my opinion, to application design as well.

Questions or comments, feel free to send them either on twitter @mattd1980 or drimonakosm@xceed.com

How does Xceed DataGrid for WPF stack up against Microsoft’s?

Odi [Xceed] — Tue, 05 May 2009 17:17:00 GMT

Today I noticed this blog post by Nigel Spencer discussing his experiences with both Microsoft's WPF datagrid and Xceed's. I liked that Nigel recognizes that any new datagrid coming out this year will be significantly behind in maturity. If you take a look at the 25 releases of Xceed's WPF grid so far, you'll see hundreds of improvements to the product over the 2.5 years it has been on the market. Not only would you have to live through that with any new datagrid coming out soon (or even in the past year), but the competition's pace will be slower. That's because Xceed's UI controls team, which used to make a variety of controls for Windows Forms, is now focused entirely on datagrids and hasn't spread its teams to design ribbons, charts and other WPF controls not directly related to datagrids.

Nigel also mentions the Microsoft WPF toolkit datagrid. Nice to see that he thinks we got a few things right that Microsoft might have missed in their v1. Here's a portion of his post:

So how does the Xceed DataGrid stack up against Microsoft’s? Here are some of the benefits that I’ve found so far:

Binding to SelectedItem works just fine.
ReadOnly properties support at Grid, Column and Row level.
CheckBox column allows simple styling whilst preserving ReadOnly value.
Automatically supports current selection and edit indicators in the row header.
The grid theme matches the OS theme out of the box. This is how it should be. Sure the grid can be custom styled to suit but it only makes sense that by default the grid should match the look and feel of the standard themed controls.
When auto-generating column headers it correctly uses any System.ComponentModel.DisplayName attributes that have been applied to the underlying class.
There are lots of options at grid and column level that determine how a cell should enter edit mode. This is very useful for columns such as CheckBox columns where requiring a click to enter edit mode can be highly annoying (since the user would expect the click to toggle the checkbox).

Here are a couple of things Nigel suggests we could improve in an upcoming version:

An easier mechanism for custom sorting. Rather than having to specific custom IComparer implemenations often it is easier to refer to an unbound property that contains the raw data. Like Microsoft’s SortMemberPath property. Hmm… I wonder if you could use a generic SortComparer to provide the same functionality?
Smaller assembly size. I know these days 2.08Mb shouldn’t be an issue but for my current contract it is. We have a ClickOnce application that is deployed to machines in remote country areas. Many of these machines are still using dial-up! Adding another another 2Mb to our current 4.5Mb total is a decision not to be made too lightly. [We’ve already been burned with a ridiculously bloated NHibernate assembly (1.6Mb)]

Thanks for the suggestions. You can be sure the team has noticed them.

I notify, we notify, we all... Wait. No we don't!

Jenny — Wed, 01 Apr 2009 18:57:00 GMT

Our support department often answers questions from customers who are wondering why grouping, sorting, and statistical functions are not updated when items in the underlying data source are changed, even though they are using a grid bound to an ObservableCollection. After all, an ObservableCollection is supposed to observe its content, isn't it? Well, actually, an ObservableCollection observes its items as a whole. In other words, it only notices when items are added or removed, not when the values of its items change, even if those items implement INotifyPropertyChanged. In comparison, a BindingList DOES listen to INotifyPropertyChanged, and therefore, if its items are modified, the changes will be reflected in the grid. As a result grouping, sorting, and statistical functions will be updated.

This nifty animation illustrates the differences between the two.

Now, if you apply these changes through the grid—in other words, edit an item in the grid—you don't have to worry about it.

WPF vs. Silverlight: it's the wrong debate

Odi [Xceed] — Mon, 23 Mar 2009 18:43:00 GMT

The question isn't "Wither WPF?" or "Will Silverlight marginalize WPF?"

With announcements at MIX09 that Silverlight will gain many of the key features that made WPF special, developers, component vendors and the media are now concerned more than ever about the future of WPF.

It's not WPF they should be worried about.

When you elect to use Silverlight, you are really choosing to forego the full .NET framework and everything that goes along with it that isn't in the latest flavour of Silverlight. Tons of useful capabilities, thousands of APIs, file system access, you name it. And also lots of new .NET 4.0 capabilities as well, like dynamic languages, MEF, parallel programming, hard-core multi-touch support, and so on, that aren't in Silverlight.

Silverlight isn't just a compact, streamlined version of WPF, it is a compact, streamlined version of the entire .NET framework. To say the debate is about whether or not you want to forego some particular WPF features that aren't in Silverlight 3 is focusing on too fine a point. The issue at hand, and the choice being made when selecting the platform to use, is much larger than that.

Think about this question instead: Do you think there will be a significant amount of developers that will continue to use the full .NET framework for their projects? Or will they be using the more cross-platform, quick-to-install Silverlight, whether they are targeting the web or not? Consider both run-of-the-mill business apps which Silverlight 3 tries to easily enable, as well as other kinds of apps, such as “media” apps like movie players and games.

If your answer is that, Yes, there will still be many developers using the full .NET framework instead of Silverlight, then you have nothing to worry about when it comes to WPF. WPF is arguably at the point where it knocks the socks off of Windows Forms. With .NET 4, Visual Studio 2010 and Expression Blend 3, WPF will be the UI framework "par excellence" for those using the full .NET framework.

If your answer is No, you think very few developers will resist Silverlight's temptations such as being able to run on OS X and potentially other platforms, then it isn't just WPF that you should be concerned about. It's the entire .NET framework, even the Windows platform itself.

After all, if there weren't enough reasons left to develop specifically for Windows, well, all that would be left going for Windows would be features. There would be fewer and fewer Windows-only apps. That seems suicidal to me, Microsoft wouldn’t let it happen without a fight. What did Steve Jobs recently say? He insists it’s the apps that will differentiate Apple’s latest product, the iPhone, from the competition.

So what’s my answer?

Yes, moving forward, there will still be plenty of developers that choose to use the full .NET framework, for not-so-run-of-the-mill business apps as well as for a million and one other kinds of apps. I'm talking about a pretty big 'Long Tail'. And many of those apps will need a UI, and that means WPF, not Silverlight. Sure, Silverlight 3 has multi-platinum superstar potential, but WPF should get a few gold records as well. I think it’s far from withering away or being marginalized, as many are worried about.

Mix09!

Matt — Fri, 13 Mar 2009 13:47:00 GMT

Next week I'm headed to Vegas to participate in this much anticipated event. I'm really looking forward to meet some of you and I will be hard to miss with my white Xceed polo ;-) so don't be a stranger! The sessions I will be attending will be mostly those concerning Silverlight 3 and WPF. I'm pretty excited about What's New in Windows Presentation Foundation (WPF) 4 by Kevin Gjerstad and Mark Wolson-Thomas, I've been working with WPF over the past three years and have pretty high expectations about this new version. I hear XAML will change a bit, which concerns me considering most of my coding time is done in XAML for the DataGrid or our Silverlight products.

My expectations for Mix09 are to a) learn new stuff and b) get inspired! It'll be interesting to see what others do and what Microsoft has planned for the future. I'll see you guys and gals there! I'll probably be tweeting quite a bit about what I am doing while I’m there so feel free to follow me at twitter.com/mattd1980. Oh and I'll be attending the TAO party with Catherine, Charles, and Odi on Wednesday night!

From WinForms to WPF – PART 3: Master/Detail

Jenny — Thu, 26 Feb 2009 19:42:00 GMT

Rarely has a feature sparked so much debate at Xceed as hierarchical master/detail. And I think that this feature made it in both the WinForms and WPF grids solely on the fact that our customer base kept requesting it. So here we are, a couple of years later, with a feature that when used appropriately can be a valid way to display information, but that can easily spiral into an incomprehensible mess. What I mean by this is that one level of detail information per master row is perfectly acceptable and legible, but throw in grouping and things start getting ugly. Add more than one detail level as well as grouping and you are in for a world of confusion. So whether you agree with me or not, let’s get started!

In order to be able to display master/detail data, the grid must be bound through a DataGridCollectionView to an underlying data source that contains hierarchical detail relations (not 100% true, but I will get to that later). The content of those relations will be displayed as the details of the data items in a grid or in another detail. Each relation is represented by a DataGridDetailDescription, which will automatically be created for:

Every DataRelation in a DataTable (DataRelationDetailDescription)
Data items that implement the IEnumerable interface (EnumerableDetailDescription)
Data items that implement the IListSource interface (ListSourceDetailDescription)

Detail descriptions can also be explicitly defined by adding them to DetailDescriptions collection of the DataGridCollectionView to which the grid is bound.

In order for the detail to appear in the grid, the grid’s AutoCreateDetailConfigurations property must be set to true. At this point, you are probably wondering what the difference is between a “detail description” and a “detail configuration”, so I will explain it before continuing:

A “detail description” is the data representation of a detail relation while a “detail configuration” is its visual representation. See? Easy.

So let’s see how this would look in code:

DataGridCollectionView view = new DataGridCollectionView( this.Orders.DefaultView );
DataGridControl grid = new DataGridControl();

grid.AutoCreateDetailConfigurations = true;

grid.ItemsSource = view;

If you have been following this series of posts, you knowthat “Orders” is a DataTable from the Northwind DataSet that also happens to contain a DataRelation (remember, these are automatically detected) to the OrderDetails DataTable.

In XAML, it would look like the following:

<Grid xmlns:xcdg="http://schemas.xceed.com/wpf/xaml/datagrid">
   <Grid.Resources>
     <xcdg:DataGridCollectionViewSource x:Key="cvs_orders"
                                                            Source="{Binding Path=Orders}"/>
   </Grid.Resources>

<xcdg:DataGridControl x:Name="OrdersGrid"
                                    ItemsSource="{Binding Source={StaticResource cvs_orders}}"
                                    AutoCreateDetailConfigurations="True"/>
</Grid>

Notice that the DataGridCollectionViewSource is used in exactly the same way to display master/detail data as it is to display data that does not have relations, that is, when you let the automatic detection of detail relations do its thing. Now, if you want to intervene in this process, you are more than welcome to do so. Here’s how.

Detail Descriptions

Every detail description must have a unique, identifying relation name that can be provided through its RelationName property and that will be used by detail configurations to identify which description their configuration will be applied to. If the detail descriptions are automatically created, their relation name will be extracted from the underlying source or a default one will be provided. If they are explicitly provided, then their relation name must also be explicitly set.

The AutoCreateDetailDescriptions property of the DataGridCollectionView class determines whether detail descriptions are automatically created when a data relation is encountered in the data source and can only be set at construction time.

OK, enough copy and paste from the documentation. Let’s look at some code that changes the title that will be used to represent the resulting details in the HierarchicalGroupByControl and in other locations where the detail title is displayed:

view.DetailDescriptions[ "OrdersOrderDetails" ].Title = "Order Details";

In XAML:

<xcdg:DataGridCollectionViewSource.DetailDescriptions>
<xcdg:DataRelationDetailDescription RelationName="OrdersOrderDetails"
Title="Order Details"/>
</xcdg:DataGridCollectionViewSource.DetailDescriptions>

Now, if we were to bypass the automatic creation of the detail descriptions, it would be necessary to create the detail description and provide it to the DetailDescriptions collection of the DataGridCollectionView before it can be accessed. Of course, adding it to the collection with its Title property already set is probably a better idea.

DataGridCollectionView view = new DataGridCollectionView( this.Orders.DefaultView, typeof( System.Data.DataRowView ), true, false );

DataRelationDetailDescription relation = new DataRelationDetailDescription();
relation.RelationName = "OrdersOrderDetails";
relation.Title = "Order Details";

view.DetailDescriptions.Add( relation );

And now the XAML version, which does not do much in this case since we only have one detail relation; however, if the source were to contain more than one relation, by setting the AutoCreateDetailDescriptions property to false, only the “OrdersOrderDetails” relation would have been created.

<xcdg:DataGridCollectionViewSource x:Key="cvs_orders"
                                                        Source="{Binding Path=Orders}"
                                                        AutoCreateDetailDescriptions="False">
   <xcdg:DataGridCollectionViewSource.DetailDescriptions>
       <xcdg:DataRelationDetailDescription RelationName="OrdersOrderDetails"
                                                             Title="Order Details"/>
   </xcdg:DataGridCollectionViewSource.DetailDescriptions>
</xcdg:DataGridCollectionViewSource>

Sibling and Child Detail Descriptions

Not only can each detail description can have one or more sibling detail descriptions (they will be contained in the same DetailDescriptions collection), they can also have one or more child detail descriptions, and so on and so forth.

Now I won’t go into detail about sibling and child detail descriptions. Just keep in mind that they work like the first-level detail descriptions, and that each has its own DetailDescriptions collection.

Ok, so now you know how to get your detail data displayed in a grid, and you know the difference between a detail description and a detail configuration.Let’s take a look at how to use the detail configurations to change the look of the details.

I have the sudden urge to count the number of times I have written the word “detail” so far...

Detail Configurations

As I previously mentioned, detail descriptions are the data representation of detail relations while detail configurations are their visual representation. Each detail that results from a detail description is configured according to its corresponding detail configuration, which is identified by its relation name (the same relation name that was used for or extrapolated by the corresponding detail description). By default, a detail configuration that contains a ColumnManagerRow and a TextBlock containing the detail title will be applied to all resulting details. Now, you can decide to change the configuration of all details, regardless of their level, through the grid’s DefaultDetailConfiguration property, or you can provide a detail configuration for a specific detail level through the grid’s DetailConfigurations collection.

Before I continue, I want to explain the difference between the default detail configuration and the configurations contained in the configuration collection. The main difference is their type: the DefaultDetailConfiguration property expects a DefaultDetailConfiguration while the DetailConfigurations collection expects DetailConfiguration types. Why? Well, since there is a direct one-to-one relation between a detail description and a detail configuration, we did not think it was a good idea to expose properties, such as RelationName and Title in the default detail configuration,since these properties could not be applied to all. So we decided to create the DefaultDetailConfiguration class, which only exposes the properties that can be applied to all details indiscriminately.

So let’s take a look at how we could use the default detail description to provide an InsertionRow in the footers of every detail:

DataTemplate template = new DataTemplate();
template.VisualTree = new FrameworkElementFactory( typeof( InsertionRow ) );

DefaultDetailConfiguration defaultConfiguration = new DefaultDetailConfiguration();
defaultConfiguration.Footers.Add( template );

grid.DefaultDetailConfiguration = defaultConfiguration;

And the XAML:

<xcdg:DataGridControl.DefaultDetailConfiguration>
   <xcdg:DefaultDetailConfiguration>
      <xcdg:DefaultDetailConfiguration.Footers>
          <DataTemplate>
             <xcdg:InsertionRow>
          </DataTemplate>
      </xcdg:DefaultDetailConfiguration.Footers>
   </xcdg:DefaultDetailConfiguration>
</xcdg:DataGridControl.DefaultDetailConfiguration>

Now if we were to explicitly provide a detail configuration for a specific detail relation, the default detail configuration would be ignored and the explicit detail configuration would be used. So let’s see how that would look:

grid.AutoCreateDetailConfigurations= false;

DetailConfiguration configuration = new DetailConfiguration();
configuration.RelationName = "OrdersOrderDetails";
configuration.Title = "Order Details";

// Do not use the default headers ( TextBlock andColumnManagerRow )
configuration.UseDefaultHeadersFooters = false;

DataTemplate cmrTemplate = new DataTemplate();
cmrTemplate.VisualTree = new FrameworkElementFactory( typeof( ColumnManagerRow) );

configuration.Headers.Add( cmrTemplate );
grid.DetailConfigurations.Add( configuration );

XAML:

<xcdg:DataGridControl.DetailConfigurations>
<xcdg:DetailConfiguration RelationName="OrdersOrderDetails"
                                        Title="Order Details"
                                        UseDefaultHeadersFooters="False">
    <xcdg:DetailConfiguration.Headers>
        <DataTemplate>
           <xcdg:ColumnManagerRow/>
        </DataTemplate>
    </xcdg:DetailConfiguration.Headers>
</xcdg:DetailConfiguration>
</xcdg:DataGridControl.DetailConfigurations>

In this situation there is one MAJOR difference between the code and the XAML: in code, the value of the AutoCreateDetailConfigurations property (which I will refer to as ACDC from now on because you can’t get a better acronym) is set to false, while in XAML, its value is of no importance in this situation. Let me explain: in XAML, when the ACDC property is set to true, the DetailDescriptions collection will be automatically populated with the appropriate detail configurations, and any items that are added to the collection will be “linked” to the existing item in the collection. If set to false (still in XAML), the collection will not automatically be populated, but by defining a configuration in the collection, it is also added at the same time. In code, as I have painstakingly learned, the ACDC property takes on a different personality... sort of... I have already explained that, when set to true, detail configurations will automatically be created and added to the DetailConfigurations collection. BUT what is not so obvious is that setting values of properties on the automatically created detail configuration does not provide the same result as creating a new DetailConfiguration for the specific detail relation. So, if ACDC remains true, you will need to replace the one that was automatically created with the new one. So to keep things simple, I would suggest you set the ACDC property to false and add the DetailConfiguration to the DetailConfigurations collection.

Custom Detail Descriptions

Remember in the first few paragraphs when I said that it was not 100% true that a data source must contain detail relations in order to display detail data? What I meant by that is that although the most common types of detail relations are automatically detected, it is also possible to create and use custom detail descriptions that will return detail items for a parent item, whatever the definition of the detail relation is.

Custom detail descriptions can be created by deriving from the DataGridDetailDescription class and overriding its GetDetailsForParentItem method to return the desired details for a data item. Now the detail data returned can be anything, as long as it is at least an IEnumerable. If a data item does not have detail data, simply return null.

I will not go into details about how to create a custom detail description, so if you want an example, you can take a look at the “Custom Detail Descriptions” topic in the documentation.

What Now?

This post ended up being much longer than I had originally anticipated! So if you read all the way to the end and have any questions or would like more information, please post it here or in the forums.

For those of you who are interested, I wrote “detail” 156 times.

Animation in xaml to get you started.

Matt — Mon, 16 Feb 2009 16:14:00 GMT

My previous post was xamlless so I thought I'd give some basic examples to get you started if you're not familiar with animations.

First I'll show you how to create this smooth translate and opacity animation and how to tweak it to what you want. Here's the storyboard I declared in my project resources :

<DoubleAnimation

Storyboard.TargetProperty="Opacity"

DecelerationRatio="0.5"

To="1"

Duration="00:00:00.400"/>

<DoubleAnimation

Storyboard.TargetProperty="(UIElement.RenderTransform).(TranslateTransform.X)"

To="0"

DecelerationRatio="0.5"

Duration="00:00:00.400"/>

</Storyboard>

There are various ways you can do this but I prefer using a more generic approach where I will not be dependent on the type of object I will be animating, hence the UIElement.RenderTransform. You could also set this explicitly by using the Storyboard.TargetName property and naming (x:Name) your TranslateTransform, which would look like this :

<DoubleAnimation

Storyboard.TargetName="myTranslate"

Storyboard.TargetProperty="X"

To="0"

DecelerationRatio="0.5"

Duration="00:00:00.400"/>

Either way, it does not really change anything for the current example. Now, the only thing left is to make sure the object you will be animating has a TranslateTransform attached and its opacity set to 0 :

<TextBlock.RenderTransform>

</TextBlock.RenderTransform>

</TextBlock>

Your control is now ready to be animated, for testing purposes you can just add the following code in your xaml :

<TextBlock.Triggers>

<EventTrigger.Actions>

</EventTrigger.Actions>

</EventTrigger>

</TextBlock.Triggers>

There are various elements you can play with to get the effect you want, at this point it's just a matter of changing the duration along with the Acceleration or DecelerationRatio and the TranslateTransform X value. Keep in mind that in a lot of cases a simple Opacity animation should be enough without adding the translate. The key is to not over do it .

Another fun yet dangerous (in a design point of view) thing to play with when working with animation, is the ScaleTransform. If you read my previous post you will understand why. ScaleTransform animation surfs on the thin line between corny and cool. Scaling elements can be intresting in splash screens or when you initially layout your elements. Here is an example :

<DoubleAnimation Storyboard.TargetProperty="Opacity"

To="1"

Duration="00:00:00.400"/>

<DoubleAnimation Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleX)"

To="1"

Duration="00:00:00.400"/>

<DoubleAnimation Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleY)"

To="1"

Duration="00:00:00.400"/>

Make sure your element has both the opacity set to 0 and has a ScaleTransform attached :

<TextBlock Text="Hello World"

Opacity="0">

<TextBlock.RenderTransform>

</TextBlock.RenderTransform>

</TextBlock>

I would advise against starting with a ScaleX and ScaleY at 0 as the effect will be too drastic. You can try it out and see what I mean.

Just to demonstrate what you could do :

So how does that all tie in the datagrid? Well, it's really up to you and your creativity. An easy example would be to use an animation like a scaleTransform in a cell's error style. If some data is invalid, you could then scale it to bring the information to the user's attention.

If you want to try this out, create a new Style with TargetType xcdg:DataCell (assuming you added Xceed's namespace with xcdg) give it a key like : myCellErrorStyle

In this style you can add something like this (tweak it to what you want) :

<Setter Property="RenderTransformOrigin"

Value="0.5,0.5"/>

<Setter.Value>

</Setter.Value>

</Setter>

<Style.Triggers>

<Trigger Property="IsValidationErrorRestrictive"

Value="True">

<Setter Property="Background"

Value="Red">

</Trigger>

<Trigger Property="IsValidationErrorRestrictive"

Value="False">

<Setter Property="Background"

Value="Orange">

<Trigger.EnterActions>

<DoubleAnimation Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleX)"

To="1.1"

Duration="00:00:00.25"/>

<DoubleAnimation Storyboard.TargetProperty="(UIElement.RenderTransform).(ScaleTransform.ScaleY)"

To="1.1"

Duration="00:00:00.25"/>

</Storyboard>

</BeginStoryboard>

</Trigger.EnterActions>

</Trigger>

</Style.Triggers>

Now, on the datagrid you have a property named CellErrorStyle, you can set it to your myCellErrorStyle and voila!

Questions? Comments? Please feel free to share :).

Public, Private, Protected, OH MY!

Jenny — Thu, 12 Feb 2009 15:18:00 GMT

How an API is designed can make or break a product. A good API will make it easy and intuitive to use the product while a poorly designed API can be an immediate turnoff. At Xceed, we spend a great deal of time designing our APIs and take great pride in knowing that, although they might not be perfect, we have made every effort to get it as close as possible to perfection. Because of my involvement in this process and my, well, strict rules and guidelines, the guys have dubbed me the "Interface Nazi". So for any of you who are interested in knowing the process that goes into a design/API meeting at Xceed, here are some inside looks at how our APIs are designed .

Design Meetings

In a normal design meeting where how a feature will work and how it will be exposed is discussed, the developers working on the feature, the project leader, and I will be there. We usually start by looking at the work that has been done by the developer and how it behaves. Next, we take a look at how the feature is exposed. This part usually involves opening up Reflector and looking at the initial version of the API as designed by the developer. Now, for an API review, we only really care about the "public" members, which includes all members that have the public, protected, and protected internal accessors. During these meetings, I bring in my dictionary (yes, the big book with lots of pages), my thesaurus (yes, I prefer books), and most importantly my copy—and I repeat MY copy—of Framework Design Guidelines, signed by Brad Abrams (yes, I am nerdy enough to get my design guidelines book signed). On a side note: EVERY .NET developer should have a copy of the Framework Design Guidelines in his or her bookshelf. If you don't, order it now. To continue: Once we start reviewing the API, this is where the fun part starts. It usually goes something like this:

Me: Why is that member public?

Dev: Because it might be useful in the future.

Me: Is it useful now?

Dev: No.

Me: Make it internal. We can always make it public later in another version when it is needed.

This, to me, is a very important part of the API design: If it does not need to be public, don't make it public. Only expose what is important to the user. You can always expose members later, but you can't remove them from the API without breaking the interface. And I HATE breaking the interface.

Spelling and the correct usage of words in an API is also very important, especially in a team where English is not always the native language. At Xceed, most of our developers can read and write in English, but sometimes, French words creep into the API. One common example is the word "edition". In French, in the context of the datagrid, this word means "to be in edit mode"; however, in English, this word usually relates to printed materials, such as books. So using the word "edition" in the API does not make sense. (If you have the Blueprint Edition, you may notice that some of the internal members still have the word "edition" in them!) Another point of contention was the verb "canceling". Do we spell it with 1 "L" or 2? It was decided that we would follow "US English" for all of our APIs, which was an easy decision since we wanted to follow the .NET Framework API as closely as possible. So 1 "L" it was!

Although these are simple examples, many people would be surprised at how much effort goes into designing an API at Xceed. I remember when we were designing the Cardflow 3D View. It took 3 weeks and about 21 API iterations before we finally settled on a design. And I say "settled" because I think that no one involved in that design is still 100% satisfied with the API.

Nearing the End

The big API review comes near the end of the development cycle. At this point I generally need the API to be finalized so I can finish the documentation in time. The meeting usually involves the lead developer and me, and we compare the latest public version of an assembly and the latest version of the one currently under development to examine the differences in their APIs. Although we still use LibCheck for this, there are many different tools that you can use such as Framework Design Studio. Equipped with coffee and lots of treats, this meeting usually lasts for the better part of the day, and it is during this final review that we try to pinpoint any breaking changes (so I can document them) and any API inconsistencies that we may have missed during the other meetings.

After this meeting and once the developers have corrected any API issues we might have found, we call an "API freeze", meaning that if a developer wants to add, remove, or rename anything that is publicly exposed, he better have a good reason and a nice bribe .

What Would Xceed Do?

Here are some guidelines that I try to enforce in our APIs:

1- It is better to make everything internal or private and expose what is needed when it is needed than to make everything public.

2- Do not sacrifice clarity for character count. If the name of a member has to be 57 characters long to make its function clear, then do it. With Intellisense, who types out full member names anyway?

3- Do what Microsoft does. If you are not certain how a member should be named, look for precedents! Often, there will be a class in the Framework that does something similar to yours. Look at its members and try to keep the naming similar. HOWEVER, you should ALWAYS follow your own precedents before adopting someone else's. For example, if throughout your API you have used ReadOnly but the Framework uses IsReadOnly, stick to yours. Uniformity in an API is a key feature of its ease of use.

Because you can animate, doesn't mean you should.

Matt — Tue, 10 Feb 2009 17:56:00 GMT

A lot has changed since WinForms but one of the variables that hasn't changed much, is the programmer. WinForms programmers who were used to static environments are now asked to "upgrade" to WPF, which brings a whole new world of possibilities. One of these possibilities is animation. In an ideal world, a company that moves from WinForms to WPF should have an integrator and an artist. Obviously, not all of WPF programmers are that fortunate and some have to take on the three roles. Here's an example of what I consider a good use of animation.

If working with Catherine (our artist) has taught me anything in the past three year is that "less is more", which she often loves to remind me. This is especially true with animations and more so if you have little or no experience with it. Stick with the basics. Why do you want to animate X and Y? The answer can't always be "because it's cool” or “because I can". Animations should be used to guide the user’s eyes on the screen, to give them a visual queue that something changed. It's easy to go over the top and do too much. Here's an example of what I would not recommend :

Unfortunately, this is the type of things we see in WPF applications. Too much visual noise, which overwhelms the user. I would recommend a much smoother approach. For example:

In the end, if your application is built around a "light" animation philosophy, odds are that you'll get a much slicker application. Try not to vary the type of animation you are using either. Mixing ScaleTransforms with RotateTransform can make a user nauseous. If you don't feel you have the knowledge required to determine when you should use animation, refer to the pros like what you see in Zune, which uses very smooth animation like the one I demonstrated.

Also feel free to follow me on twitter !

Microsoft Tag in MSDN Magazine February 2009 issue.

Odi [Xceed] — Mon, 09 Feb 2009 20:55:00 GMT

When Microsoft Tag was announced at CES 2009 on January 7th, the official deadline for submitting ad material for the February 2009 issue of MSDN magazine (the print publication) was already passed. But I knew it still wasn't too late, most magazines always keep a safety buffer for late submissions. So we created a tag on the Microsoft Tag site, added the tag to our latest printed advertisement with the word "Surprise!" near it, and re-submitted February's material. It made it into the February issue! Visit the tag for a nice surprise (if you're interested in a fantastic datagrid for WPF development.)

Here is what the ad looks like (it is a two page spread ad, and the tag has been partially hidden here on purpose, you must get your hands on an MSDN magazine to get to the tag itself):

Is it the first use of Microsoft Tag in a printed magazine? Close, but there's this one, and perhaps one in a newspaper which doesn't require materials so long in advance.

Add this technology to the list of Microsoft technologies Xceed has been the first (or one of the first) to use :)

From WinForms to WPF - PART 2: Sorting and Grouping Data

Jenny — Fri, 06 Feb 2009 17:26:00 GMT

In Part 1 of this series, I demonstrated how to provide a grid with data. This post will continue where I left off and demonstrate how to group and sort the same data, so if you have not looked at Part 1, I suggest you do so.

Ready?

Data items can be sorted by adding SortDescription structures to the SortDescriptions collection of the DataGridCollectionView to which a grid is bound and specifying the field name of the column by whose values to sort, as well as the direction in which those values are to be sorted. Let's look at some code:

view.SortDescriptions.Add( new SortDescription( "ShipCountry", ListSortDirection.Ascending ) );
view.SortDescriptions.Add( new SortDescription( "ShipCity", ListSortDirection.Ascending ) );

In the above code, two SortDescription structures are added to the SortDescriptions collection of the DataGridCollectionView ("view") to which the grid is bound. The result is that the data items of the grid are sorted according to the values of the ShipCountry and ShipCity columns.

Groups are created in basically the same way; however, rather than adding SortDescription structures to the SortDescriptions collection, DataGridGroupDescription objects are added to the GroupDescriptions collection. For example:

view.GroupDescriptions.Add( new DataGridGroupDescription( "ShipCountry" ) );
view.GroupDescriptions.Add( new DataGridGroupDescription( "ShipCity" ) );

As mentioned in Part 1, the DataGridCollectionViewSource is the XAML representation of the DataGridCollectionView. So let's see how the above code translates to XAML. But before we do, we need to map the System.ComponentModel namespace in the WindowsBase assembly that will allow us to use the SortDescription structure. You can add the new namespace declaration to your window or to the grid that contains the datagrid control.

xmlns:scm="clr-namespace:System.ComponentModel;assembly=WindowsBase"

Let's get on with the show!

<xcdg:DataGridCollectionViewSource x:Key="cvs_orders" Source="{Binding Path=Orders}">
   <xcdg:DataGridCollectionViewSource.SortDescriptions>
      <scm:SortDescription PropertyName="ShipCountry" Direction="Ascending" />
      <scm:SortDescription PropertyName="ShipCity" Direction="Ascending" />
   </xcdg:DataGridCollectionViewSource.SortDescriptions>

   <xcdg:DataGridCollectionViewSource.GroupDescriptions>
      <xcdg:DataGridGroupDescription PropertyName="ShipCountry" />
      <xcdg:DataGridGroupDescription PropertyName="ShipCity" />
   </xcdg:DataGridCollectionViewSource.GroupDescriptions>
</xcdg:DataGridCollectionViewSource>

Now, when SortDescriptions and DataGridGroupDescriptions are added to a DataGridCollectionView or DataGridCollectionViewSource, they represent the INITIAL sorting and grouping criteria that are applied to the content of a grid. Once an end user changes these, the ones that were initially added will no longer be used. This can be especially problematic with group descriptions since any customization that was done to the initial descriptions, such as providing a specific GroupConfiguration, will be lost. But don't panic! As you will see, there is a very easy solution to this problem!

Custom Group Descriptions and Configurations

Each DataGridGroupDescription exposes a GroupConfiguration property, which determines the appearance the groups will have once they are created. If a custom group configuration is provided to the initial DataGridGroupDescription, it will be lost once the group is removed by the end user. This is where the GroupDescription and GroupConfiguration properties, which are exposed by the Column class, come in handy. The DataGridGroupDescription and GroupConfiguration that are provided to these properties, respectively, will be used whenever the content of the grid is grouped by the values of the column. Of course, if you have a custom DataGridGroupDescription that already has a GroupConfiguration, you don't need to provide the GroupConfiguration to the column.

So, let's assume that we have a GroupConfiguration that needs to be used every time the content of the grid is grouped by the values of the ShipCountry column. If this were done in code, it would look something like the following:

DataTemplate template = new DataTemplate();
template.VisualTree = new FrameworkElementFactory( typeof( InsertionRow ) );

GroupConfiguration configuration = new GroupConfiguration();
configuration.Footers.Add( template );

grid.Columns[ "ShipCountry" ].GroupConfiguration = configuration;

Although the above code demonstrates how to create a template in code and add it to the Footers collection of the GroupConfiguration, DO NOT CREATE TEMPLATES IN CODE! EVER! FrameworkElementFactory is deprecated and the API in code does not allow you to do as much as it does in XAML. Now that I got that out of my system, let's look at the equivalent XAML:

<xcdg:DataGridControl.Columns>
   <xcdg:Column FieldName="ShipCountry">
      <xcdg:Column.GroupConfiguration>
         <xcdg:GroupConfiguration>
            <xcdg:GroupConfiguration.Footers>
               <DataTemplate>
                  <xcdg:InsertionRow />
               </DataTemplate>
            </xcdg:GroupConfiguration.Footers>
         </xcdg:GroupConfiguration>
      </xcdg:Column.GroupConfiguration>
   </xcdg:Column>
</xcdg:DataGridControl.Columns>

Much better

Custom Sorting

In addition to the default type-based sorting, custom sorting can also be applied by providing an IComparer to the SortComparer property of one or more DataGridItemProperties defined in the DataGridCollectionView or DataGridCollectionViewSource to which a grid is bound. This comparer will be used whenever the values of the corresponding column are sorted (e.g., clicking on the column header). For example, I have created a custom sort comparer (AddressComparer class) that compares addresses first with their civic number, followed by the street. This comparer is then provided to the ShipAddress DataGridItemProperty and will be used whenever the ShipAddress column is sorted.

First, the code:

DataGridItemProperty addressProperty = new DataGridItemProperty( "ShipAddress", typeof( string ) );
addressProperty.SortComparer = new AddressComparer();

view.ItemProperties.Add( addressProperty );

Now, the XAML:

<local:AddressComparer x:Key="addressComparer"/>

<xcdg:DataGridCollectionViewSource.ItemProperties>
<xcdg:DataGridItemProperty Name="ShipAddress" SortComparer="{StaticResource addressComparer}" />
</xcdg:DataGridCollectionViewSource.ItemProperties>

You'll notice that the AddressComparer class is located in the "local" namespace. This namespace must be declared in order to be able to use the AddressComparer class. The class also needs to be declared in the resources of the Grid (not the DataGridControl class), above the declaration of the DataGridCollectionViewSource.

xmlns:local="clr-namespace:WinFormsToWPF"

Knowing When Sorting and Grouping Change

A common question that has been asked by many clients is "How do I know when the grouping or sorting changes?". And many get frustrated when they don't find "group changed" or "sort changed" events. The solution, however, is easier than you might think!

Both the GroupDescriptions and SortDescriptions collections exposed by the DataGridCollectionView class implement the INotifyCollectionChanged event, which has a CollectionChanged event that can be handled to know when either collection changes. First, in code:

DataGridCollectionView view = new DataGridCollectionView( this.Orders.DefaultView );

( ( INotifyCollectionChanged )view.GroupDescriptions ).CollectionChanged += new NotifyCollectionChangedEventHandler( GroupDescriptions_CollectionChanged );
( ( INotifyCollectionChanged )view.SortDescriptions ).CollectionChanged += new NotifyCollectionChangedEventHandler( SortDescriptions_CollectionChanged );

Now, in XAML:

Actually, this can only be done in code; however, when the grid and DataGridCollectionViewSource are defined in XAML, the location where the events are subscribed to is not the same. In the code above, the CollectionChanged events were subscribed to right after the DataGridCollectionView was created. In the case where the collection view is defined in XAML, the events can only be subscribed to after the grid and collection view have been created. The location I usually choose for this is the OnInitialized override of my main window:

DataGridCollectionView view = this.OrdersGrid.ItemsSource as DataGridCollectionView;

if( view != null )
{
( ( INotifyCollectionChanged )view.GroupDescriptions ).CollectionChanged += new NotifyCollectionChangedEventHandler( GroupDescriptions_CollectionChanged );
( ( INotifyCollectionChanged )view.SortDescriptions ).CollectionChanged += new NotifyCollectionChangedEventHandler( SortDescriptions_CollectionChanged );
}

Conclusion

That's pretty much it! The next tutorial-and I promise to get it out much faster than it took me to get part 2 out-will deal with master-detail scenarios.

Thanks for reading!