>Re: Productivity - I am just at the beginnings of WPF but the first thing that struck me about controls defined in XAML was "My God those are just big 'ol chunks of text that completely define a control and can be inserted anyplace and cut and pasted and stored and snippet/field subsitututed and .... "
>
>I've been writing a lot of Winform components to drop on forms and do magical things and to do them right definitely takes longer that the XAML approach.

It depends. There are various levels of writing a WPF custom control - ranging from a simple UserControl derived class which is *definitely* simpler than in Winforms to deriving directly from, say, FrameworkElement at which point you have to handle rendering etc. in your own code. But I don't think the latter approach is needed very often. But if it is needed then it's available and at that level also easier than attempting the same thing in WinForms.

I just think the whole idea is very cool, especially when I'm sure there are tools (Blend?) that can write some pretty fancy XAML the way Dreamweaver writes pretty fancy HTML which you can eat as served or season to taste and which can then be the subject of the kind of cutting and pasted that allows reuse.

I've played with a copy of ExpressionBlend but I don't know it well and leave that side to others. But once ExpressionBlend has had a chance to regenerate the XAML then it's much harder to interpret since it's usually bulked out with a lot of attributes etc. that aren't really neccessary. My pet peeve is that it's too easy for an ExpressionBlend guy to inadvertently override property inheritances that you actually want to preserve. I must admit that, given my druthers, I'd rather see ExpressionBlend usage limited to generating things like complex gradients and animations on a standalone basis and just pasting the result into existing XAML. But the bottom line is that I don't know ExpressionBlend well enough to know if they are using it to it's best advantage....

>
>>>>>>>>
>>>>>>>>There was a nice demo on DNR TV showing a REAL business application put together with WPF:
>>>>>>>>
>>>>>>>>http://www.dnrtv.com/default.aspx?showNum=115
>>>>>>>>
>>>>>>>>It gives you a better idea of what is possible. The one question to ask yourself (esp. if you have a vertical market app) - how hard of a time would I have selling my app if I was competing a vendor that had an app that looked like that vs my current app? Regardless of features people have a (positive) gut reaction to attractive UI's.
>>>>>>>
>>>>>>>Thanks Paul
>>>>>>>
>>>>>>>I watched the video. Certainly the app looked nice.
>>>>>>>
>>>>>>>From the implied size of the development team I would also guess its not cheap.
>>>>>>
>>>>>>He said three people, three months so far I believe.
>>>>>>
>>>>>>But I'm sure that this could be done by one person in half that time in VFP <bg>
>>>>>
>>>>>Did I say that ?
>>>>>
>>>>>No I didn't but three people three months so far . How much would you reckon on that costing.
>>>>>
>>>>>90% of the functionality could be supplied very quickly (not necessarily in Fox). Spending a lot of time in how something looks may not be cost effective. For instance the yellow stickies.
>>>>
>>>>Did you see the code demo for those at the end of the video. It *doesn't* take a lot of time or effort. The amount of code is minimal. I've got a scrolling listbox built on the same principal. It took an hour or so - but of course you can spend more time playing with gradients etc. if you want to.
>>>>
>>>>At a guess the biggest challange they face will be defining the 'best-match' alogrithm between the employers requirements and employee skills/availability.
>>>>Best,
>>>>Viv
>>>>
>>>>>
>>>>>BTW reading some Elmore Leonard at the moment (Fire in the Hole) enjoying it.
>>>
>>>Well I think that Paul has a point that an application to be sold is going to market better when it has all the visuals but for a system developed for one client it would be a mistake to get too hung up on how it looks. The only benefit would be if you used that application as a selling point to other clients and that might not always happen. I noticed in the video the repetitive thanks to the client.
>>>
>>>A bit like getting cheap double glazing by having a big advert stuck on the side of your house.
>>
>>Leaving aside the issue of whether a 'showy' interface is beneficial (and I assume you agree that the UI was pretty user friendly) my point was that it does *not* take longer to develop in WPF compared to Winforms. Longer to learn -yes ; longer to develop - no.
>>
>>Another point made in the video, almost in passing, is that they intend to make this app available on the web using SilverLight. Although that implies some additional work most of the code base should be usable.
>>
>>FWIW I first saw this video a long time ago when just starting with WPF and remember thinking 'that looks complicated'. Now I know it is not.