Tuesday, January 22, 2008
« CSLA .NET 3.5 Jan 15 preview release | Main | Why enable the data portal behind a web ... »

in a recent email thread someone was wondering why component vendors are being so slow in coming out with grid controls for WPF/XAML.

One obvious reason is that grid controls are hard to build, and WPF/XAML is radically different from Windows Forms or Web Forms. But still, it is fair to wonder why these highly experienced control vendors haven't overcome that challenge.

I think the reason is that technology isn't the issue. At least not in the raw "learn how to use XAML" way. I think the real issue is much bigger!

Consider the incredible risk a vendor would assume by creating a grid control now.

Microsoft hasn’t come out with a WPF grid, and so there are no standard interfaces in .NET to support data binding to a grid. Certainly the current interfaces used by WPF are not nearly powerful enough to get in-place grid editing like we have in Windows Forms – and that’s a requirement if WPF is ever going to replace Windows Forms for business development.

Windows Forms and Web Forms both have benchmark grids from Microsoft. They set the standard, and define the core interaction used by data binding. The other vendors can then build around that core to do cool stuff. In particular, Windows Forms defines a whole set of powerful interfaces to allow in-place editing so the user can navigate freely in a grid, edit cells, add rows and delete rows – and press ESC to cancel changes to whatever row they are on. All features most users would consider critical to the in-place experience. The majority of those interfaces are not used by WPF today!! Nor does WPF have replacements for them. And if they do replace those interfaces then you can’t bind to a DataTable, which shuts out most developers from WPF again – probably a bad idea.

The WPF team has already shown that they’ll supersede existing interfaces (INotifyCollectionChanged was invented even though IBindingList was already there). So it is somewhat hard to predict where Microsoft might go in this regard. It is quite possible they’ll do the “worse of all worlds” and support the DataTable (all the existing Windows Forms interfaces) and invent a whole new model as well… (again, see INotifyCollectionChanged – invented for WPF, but IBindingList is also fully supported by WPF)

So in WPF the poor component vendors are really stuck. There’s no defined standard for this kind of data binding, so they need to invent it. They’ll each invent something different from the other vendors – and NONE of them will likely match whatever Microsoft eventually does. That means they are all in deep trouble when Microsoft does set the standard. And so are all consumers of those grids (all of us!).

This is very much like pre-ODBC database access, except in this case it is a very safe bet that “ODBC” is coming (in the form of some standard grid definition) and so investing in building a proprietary solution is a known dead-end. A waste of money and very likely a way to make many, many angry customers who may hate you forever.

Nasty business just now… :(

WPF

Tuesday, January 22, 2008 2:28:29 PM (Central Standard Time, UTC-06:00)
I am actually in a project, where I need to decide to go for WPF or WinForm still..
Of course my application needs some databinding to database...

Does it means that it is too early to move to WPF and we still have to go on with WInForm for a while ?

For my project, Irt has to be release for beginning of next year but I need to make a decision of which technology to use for my UI. And as I have too build many, I could not imagine to do them with Winform and change them all after 6 month..

Any advise ?
regards
Serge
MCAD.NET
Tuesday, January 22, 2008 4:36:54 PM (Central Standard Time, UTC-06:00)
I had to make the same decision some time back and with the absence of a datagrid in WPF it was quite an easy one to make. I went with .NET 2.0 WindowsForms. I think Microsoft really needs to implement a datagrid for WPF before they'll see it being taken seriously as a business app platform.
Tuesday, January 22, 2008 6:41:16 PM (Central Standard Time, UTC-06:00)
There are a few component vendors that have grid implementations now. The major component suite vendors do, anyway. I believe these had .NET grids long before the modern .NET 2.0 grids.

Granted, there was a 1.0 grid that did the basics, but I believe the component vendors are still going to forge ahead.

Having said that, with the WPF/WinForms interop, you do not necessarily have to choose one over the other. You can easily use a WinForms grid in a WPF application. Of course, it is not quite as clean as a native solution, but still works well, from my testing at least.
Wednesday, January 23, 2008 1:08:53 PM (Central Standard Time, UTC-06:00)
We've implemented a major WPF app with .net 2.0 infragistics grid because of the very problem this post describes - there is nothing comparable in terms of robustness to 2.0 grids. The seamless interop between WPF and 2.0 however makes it all a non-issue even if it is less than ideal.
Pondo
Wednesday, January 23, 2008 5:49:48 PM (Central Standard Time, UTC-06:00)
Allow me to be a bit of a contrarian.

First off, I don't really miss not having a data grid in WPF. Data grids are used for two main things:

1. Spreadsheet like UI, with in-place editing

2. a fancy multi-column list box.

I've always considered #1 a kludge 90% of the times it's used. I think it's usually lame UI. Even when you don't know the columns until runtime, I find it's far better for the user to create a real form for entry instead of making them use a grid. So I don't miss a WPF data grid for #1, because I very seldom settle for such UI.

For #2, WPF has a far superior replacement, in the form of templated ListBox and ListView controls. You can make a ListBox look just like a traditional grid, but you also have complete flexibility in how items are displayed for selection. So I don't miss a data grid for that purpose either. (You can even do in-place editing if you want to, though admittedly it's more trouble than with a data grid.)

I think the real problem 3rd party vendors have is not so much that they don't want to be "orphaned" by Microsoft's version later. It's simply that no one really knows what a data grid ought to look like in a WPF world. It's time to move beyond the simple spreadsheet metaphor, but nobody really knows what the new metaphor ought to be.

The first 3rd party to get it right and nail the new metaphor will reap some significant returns. They even be bought by Microsoft to obtain the design. So there's a pretty good reason to give it a try. But they can't just mechanically plop out a grid. They must experiment and adapt, and that takes time.

Probably some of them don't have the time and resources to do the experimentation, so they're doing wait-and-see. But I don't think that the reason no vendor has done it right yet.
Thursday, January 24, 2008 2:47:46 AM (Central Standard Time, UTC-06:00)
Maybe it's because NOBODY's actually using WPF besides a few of the graphic wonks... there's no market to sell to there, although a decent grid might create one because I've heard your argument from a number of customers as well.

But the issue of adoption is pretty serious if you think about it. WPF has now been around in release for almost a year and quarter and to date you rarely hear a peep about WPF adoption. There's very little WPF expertise out there, and those that do are probably at the extreme high end with commensurate rates.

One has to wonder what Microsoft's plans are? Silverlight rescuing WPF with a lighter model and raising WPF awareness?

That's pretty sad for a technology coming out of Microsoft. It may not even be that the technology is too hard or too different, but also that Microsoft has done such a crappy job positioning the technology that it's not likely to get more popular anytime soon. Where the heck does it fit? Certainly not for line of business applications at this point. High end consumer apps maybe but not much of a market for a component vendor to sell to. Further when you're dealing with only the high end of developers selling components is a losing battle - those folks, especially the graphics oriented ones - won't buy components off the shelf. They (think?) they can do better by themselves.
Thursday, January 24, 2008 11:02:35 AM (Central Standard Time, UTC-06:00)
I usually agree with you, Rocky, on technical, especially architectural stuff, but I have to disagree here.

Infragistics has had a WPF grid since well before WPF was released, and we released the first version of NetAdvantage for WPF just a couple months after WPF 3.0 went RTM. Also in that product, we have the new carousel controls and a few other data presentation metaphors (e.g., card view) using the DataPresenter, which has a fully pluggable view architecture that builds on our rich databinding. (And we are still giving away our Grid in our Express version, BTW.)

I'd further suggest that while Microsoft does set the standard for the very basic scenarios and, in particular, APIs, they have never really set the standard for richer scenarios (e.g., hierarchical grid), which is where we third-party vendors thrive and in a sense have always set the standards.

I'll have to also disagree with Rick in that WPF adoption is not as abysmal as the portrait he paints. Certainly, it's not replacing WinForms yet, but that was not expected. The idea that it is only for "graphic wonks" is a misperception caused because of the focus on the very real benefit that XAML and declarative triggers (and Blend) bring to the table to enable visual and interactive designers to work directly on projects. With WPF and (in the future with Silverlight), the paradigm of apps will continue to shift towards more investment in good UX (not just in the UI layer). The initial release of WPF is the first step in that shift, IMO.

I'll agree with Billy in that I think grid editing is overused, but the reality is that it is a very familiar paradigm for both devs and end users and that there are even some scenarios where it is indeed the right choice, particularly in fast data entry scenarios. But I do think Billy is on the right track there.

Finally, I point you to Brad Abram's recent post to illustrate the reality of the 3rd party space in regards to WPF right now: http://blogs.msdn.com/brada/archive/2008/01/23/wpf-coming-into-the-mainstream.aspx.
Comments are closed.