What's a broad statement? If you're going to challenge someone's statement, quote that statement in your reply so I know what I need to respond to.

Since you didn't specify exactly what statement you're challenging, I'll try to cover several things here, in no particular order.

Like any technology, WPF may or may not be applicable to your environment.

Have you tried the new tools in VS2010? They make WPF so much easier. You don't need to be a graphic designer.

You need to start thinking outside the box (both figuratively and literally - think the gray rectangle that is a Winform) and ask what additional value you can give to your users by using WPF. I don't know exactly what your applications do, but here's an example. With WPF it is easy to include anything in a combo box. So, when you have that combo box with 10,000 inventory items, you can not only include a name/description/part number, you could also include a picture of that item. It's not that you can't do that in WinForms, but it's MUCH easier with WPF.

Tim was right when he said the video system in Windows was old. In fact, it dates back to Win95. It hasn't been updated in that long while hardware (both the video card and monitor) have made HUGE advances. Software hasn't kept up. Take a look at what Markus Egger says about it. http://www.vfpconversion.com/blog/markuseggerblog.aspx?blogid=6a0addce-851e-4579-9306-0297254a1473&startdate=12/1/2005%2012:00:00%20AM&enddate=1/1/2006%2012:00:00%20AM&messageid=1f7ddedd-89e0-4f84-aad5-ccb4935a1251. Those problems exist in Winforms because of the underlying technology. WPF fixes alot of the issues.

Could Microsoft create better Winforms controls? Sure. Would it make Winforms any better? No. It would simply duplicate what 3rd parties are doing, but not address any of the problems Markus talked about.

If you work properly with WPF, once you get the hang of it, it isn't any more difficult to use than Winforms, especially in VS2010.

>That’s a pretty broad statement with very little meat to back it up.
>WPF s an attempt to fill a need that simply doesn’t exist in line of business applications. We have no need of a platform that allows graphic designers to paint up forms or controls . Most line of business applications I’ve worked on since win 3.0 don’t even stray from the standard controls. A typical Business form is pretty straight forward. You have a list of some type or search criteria and a details section or page. The details will have some validations and maybe some custom formatting. If you work in a team or have been coding for a while you probably already have base class forms to handle some or most of the query and crud logic on your business objects. So that just leaves dropping controls on the form wiring up the data binding. The majority of the data binding is usually a simple matter of putting the field name in a binding property, pretty fast and straight forward. Any validation are equally fast and straight forward. Go to the property sheet click the events button choose the valid event and dbl click to get your stub. Call your business rule or write your valid code. Again Fast and straight forward
>The users will be presented with exactly what they need exactly how they need it. And guess what else none of it will require a 3D graphics card. That’s fairly improtant in an organization with thousands of workstations.
>We don’t need yet another MS markup wana b language (AXML) for that . Just the fact that you have to go into the axml file and hand code things precludes it be more productive than WInforms.
>
>Now I’ve pointed out why I don’t see value in wpf in a line of business application. Can you show me where there is a value?