WPF grid: where the bleedin' edge can be sharp

One of the things we showed off at DevConnections last week was the latest pre-alpha iteration of our WPF Grid.

The devs responsible for our snappy ASPxGridView, Andrew and Mike, have been heads down in WPF and XAML internals over the past several months, understanding the platform and seeing how to bend it their will. And, of course, the ASPxGridView occupied some of their time too: witness the changes to appear in DXperience v2007 vol3.

You may think this is bizarre: an ASP.NET grid and a WPF grid are indubitably very different beasts. Surely we have devs just sitting around playing CounterStrike, eager and ready to take on a new project like WPF? Well, no, actually. Work never seems to stop in the DevExpress labs. Besides which, there are a lot of similarities between writing a control like the grid for ASP.NET and WPF.

First and foremost, it's all about the visuals. ASP.NET pretty much forces you to that point (the browser is a fairly primitive execution engine and is far better at showing stuff), and it's the whole premise of WPF. Second, it's all about styling: gone are the days of having a control with a bazillion different properties and methods for altering the appearance. Today it's CSS and styling using XAML. Third, it's about reusing the data access components we've already spent a great deal of time implementing, testing, stressing, making rock-solid.

All in all, Mike and Andrew were the best people we have to do the job. They know grids inside out (Mike wrote the original XtraGrid, the very first third-party .NET control ever released, and the first one with source code too). And what a great job they've done so far.

Let's see. At present the grid displays record data in a tabular form, rows and columns, with the rows corresponding to records and the columns to the fields of those records. Bog standard stuff. There is already support for unbound fields (calculated fields, if you like). We have sorting and grouping to many levels. It can calculate overall footer-type totals as well as group summary totals. Of course, the grid has the large dataset support we've been talking at length about in our marketing with regard to our ASPxGridView and XtraGrid. Let me tell you, this grid is fast, no matter whether you are sorting or grouping or displaying data from a dataset with many tens of thousands of records. And frugal with memory at the same time. (I seem to recall something in Computer Science that says you can have speed or small memory consumption, but not both. We seem to have broken that rule.)

And we've spent a great deal of time thinking about and designing for the ability to easily style everything in sight (just look at those rounded corners on the first row of the detail grid as an example). In doing so, we ran into some limitations of the WPF Framework. For example, the ListView class would seem to be the ideal class to use for something like the grid, since it displays items in a list. Just make a template for a row to show the fields and Bob's your uncle, as we say in England. Except it was designed for a small number of items, not for thousands. (We used it as the basis of our jog wheel selector in our demo, for example.) When you load thousands of items into the ListView, you have to create not only the data structures to hold the data, but also the visual elements to hold it all. Massive huge whopping memory usage, that's what happens, and that's before you start worrying about how to style it all. And it just didn't have the number and breadth of styling entry points we wanted to expose.

Hence one reason we're not at the forefront of releases for WPF controls is that we won't compromise on performance and features just to be first. We also wanted to be quite sure that we designed our grid for the WPF environment and that means giving designers the ability to style the look of the grid, whether though tweaking XAML or using a designer. Writing anything in WPF is a delicate balance between writing traditional imperative code in C# or VB or C++ and writing declarative code in XAML. The end result was that we decided to write our own container element for the grid and not reuse something that's manifestly not up to the job. Er, yes, that would be extra work, but well worth it we believe, even though it takes longer to get the control out.

So, where do we stand? Well, if you just wanted a WPF grid to display data, we could just about release tomorrow, albeit without documentation and a designer for VS2008 and a bunch of other things. Of course no one really wants just that, they also need the ability to edit the data in the grid. We've already shown that we can style individual cells (see the "check box cells" in the image), and an editor is "merely" just another style applied to a cell. If only it were that easy, but there are a lot of issues still to take care of. Nevertheless, progress on the remaining work (designers, editing, demos, documentation, etc) for the WPF grid is looking good.

We are also looking forward to getting our hands on the RTM of Visual Studio 2008 so that we can discover, along with everyone else on the planet, exactly what the WPF designers and interfaces (aka Cider) are like and how easy they are to use. I know there's already a designer application out there, but please don't ask me about Microsoft Blend, I tend to froth a bit at the mouth.

All in all, the WPF grid won't be released this year. Early next is our current in-house prediction. As usual though we do not give out actual release dates so you'll have to be satisfied with that deliberately hedged and ambiguous timetable. I dare say we'll be looking for some beta test sites before release, so if you are a DXperience Enterprise customer and are looking at WPF, drop me a line.

A word of caution though. It's going to take time for us to create the other controls we have for WinForms on the WPF platform, at least those that make sense. Do not expect us to magically declare a whole slew of WPF controls over the next six months (say). It isn't going to happen. Indeed, we're very much of the opinion that WinForms is not going to suddenly disappear overnight in favor of WPF. It's going to take time for the community as a whole to understand what can be done with WPF, what even makes sense to be done with WPF, how VS2008 is going to shake out, how Blend is going to progress, and so on. Be at the bleeding edge if you want, but we have to balance progress in this direction with all the other directions we're actively pushing forward in.

Free DevExpress Products - Get Your Copy Today