Software changes do not occur overnight!

I have been 'meddling' a little with WPF at long last, and am in all likelihood going to Echo what has been said before. As a one man band, I’m continually looking for utilities that will increase my productivity, but not at the expense of quality. It’s for this reason that I see the acquisition of controls from http://www.componentone.com/, http://www.telerik.com/, http://www.componentfactory.com/, http://xceed.com/ et al, as (this will come as a surprise) essential in the speeding up the development process.

 After (eventually) traipsing through a tutorial at http://blogs.msdn.com/tims/archive/2007/06/13/wpf-hands-on-lab-build-an-outlook-2007-ui-clone.aspx I’ve come to the realisation that you’re either a designer or a programmer (shock horror). Linq may increase productivity, but this is voraciously negated by the amount of time it will take to get your UI right in Expression Blend and Visual Studio. All the companies above have little to no components that are ready (bar the lovely data grid view from Xceed – it’s simply gorgeous) . Why should I have to undertake the task of writing a scheduler (calendar) just because I need one for my app. WPF doesn’t even offer a data grid view in its present iteration, honestly?

Working through the Microsoft Acropolis projects, that is as immature as WFP (well it’s based on it). The idea though is an excellent one but the level of immaturity of WPF and the unavailability of R.A.D components from Microsoft (no data drid view) or other vendors makes this something to get excited about in a while. Just not now, that’s all!

vesuvius wrote:

After (eventually) traipsing through a tutorial at http://blogs.msdn.com/tims/archive/2007/06/13/wpf-hands-on-lab-build-an-outlook-2007-ui-clone.aspx I’ve come to the realisation that you’re either a designer or a programmer (shock horror). Linq may increase productivity, but this is voraciously negated by the amount of time it will take to get your UI right in Expression Blend and Visual Studio.

What's with this part:

Tim's Blog wrote:

Two engineers from Microsoft Switzerland, Ronnie Saurenmann and Ruihua Jin, have put together this 90-page lab that starts at File / New Project and ends with a facsimile of the Outlook 2007 user interface.

It takes 90 pages just to come up with the interface?

Not an especially dazzling one either, it's not a faithful clone. When you start the Outlook UI project, significant amounts of work have occured already getting the UI controls set up. Double the 90 pages or triple them if you take how long it took setting all the gradient brushes and UI user controls.

To be fair, the goal of the tutorial is not to lead you through the steps to produce Outlook in the minimum number of pages, but rather to provide a comprehensive learning guide to our designer and developer tools while building a fun and useful sample.

(And that's not to say that building an Outlook-like interface is a trivial task, either - particularly if the controls are real, working, data-bound controls. I'm sure it was significantly more work for the Outlook developers to build this code in Win32.)

vesuvius wrote:



I have been 'meddling' a little with WPF at long last, and am in all likelihood going to Echo what has been said before. As a one man band, I’m continually looking for utilities that will increase my productivity, but not at the expense of quality. It’s for this reason that I see the acquisition of controls from http://www.componentone.com/, http://www.telerik.com/, http://www.componentfactory.com/, http://xceed.com/ et al, as (this will come as a surprise) essential in the speeding up the development process.

Personally, with WPF's lookless controls, I've found it rather unnecessary to use 3rd party controls.

vesuvius wrote:

 After (eventually) traipsing through a tutorial at http://blogs.msdn.com/tims/archive/2007/06/13/wpf-hands-on-lab-build-an-outlook-2007-ui-clone.aspx I’ve come to the realisation that you’re either a designer or a programmer (shock horror). Linq may increase productivity, but this is voraciously negated by the amount of time it will take to get your UI right in Expression Blend and Visual Studio. All the companies above have little to no components that are ready (bar the lovely data grid view from Xceed – it’s simply gorgeous) . Why should I have to undertake the task of writing a scheduler (calendar) just because I need one for my app. WPF doesn’t even offer a data grid view in its present iteration, honestly?

The vast majority of the use cases I've had for a "data grid view" have been easily worked up using ListView with a GridView and some styling.

The productivity comes from the unbelievable data binding.  Not a designer?  Follow the M-V-VM pattern religiously and slap together an ugly UI, then let a real designer make it pretty.  Honestly, the data binding capabilities make it possible to realize a "lookless" application that can be "painted" by a designer with little effort.  Of course, the ViewModel should be designed with some UX thought up front, so I'm not advocating completely ignoring the designer until the end.

The premise of WPF was never to eliminate the need for both developers and designers (some people do successfully wear both hats), but to make the efforts of the two seemless and more efficient.

vesuvius wrote:

Working through the Microsoft Acropolis projects, that is as immature as WFP (well it’s based on it). The idea though is an excellent one but the level of immaturity of WPF and the unavailability of R.A.D components from Microsoft (no data drid view) or other vendors makes this something to get excited about in a while. Just not now, that’s all!

These technologies are brand new.  Expecting anything other than this is foolish on your part, and a rant about it is misplaced frustration.

That said, once you can get over the incredibly large learning curve, I'm find WPF to be an incredibly exciting technology that does allow me to be very productive.

Tim Sneath wrote:

To be fair, the goal of the tutorial is not to lead you through the steps to produce Outlook in the minimum number of pages, but rather to provide a comprehensive learning guide to our designer and developer tools while building a fun and useful sample.

(And that's not to say that building an Outlook-like interface is a trivial task, either - particularly if the controls are real, working, data-bound controls. I'm sure it was significantly more work for the Outlook developers to build this code in Win32.)

I suppose the logic here is that "in the era of 1,000+ page programming books, what's another 90 pages?"

Out of curiousity, how hard is it to write your own WPF controls anyway?

thumbtacks2 wrote:



Tim Sneath wrote: To be fair, the goal of the tutorial is not to lead you through the steps to produce Outlook in the minimum number of pages, but rather to provide a comprehensive learning guide to our designer and developer tools while building a fun and useful sample. (And that's not to say that building an Outlook-like interface is a trivial task, either - particularly if the controls are real, working, data-bound controls. I'm sure it was significantly more work for the Outlook developers to build this code in Win32.)

I suppose the logic here is that "in the era of 1,000+ page programming books, what's another 90 pages?"

Out of curiousity, how hard is it to write your own WPF controls anyway?

The first thing to learn, is that you hardly ever need to write your own controls.  Templates, styles, attached properties and markup extensions can all be used in creative ways that replace many of the reasons you'd create a custom control in other frameworks, such as WinForms.  Like I said, I've made use of ListView and GridView several times for things that would have required a DataGrid in WinForms simply by applying a little bit of styling and templating.  It's really quite amazing what you can accomplish here with out creating a custom control.

If you do need to create a custom control, it's extremely easy.  Much easier than in WinForms where control compisiting requires a lot of grunt work and painting of controls is tedious and difficult.  In WPF, your control class cares only about functionality, since the controls are "lookless".  That's extremely easy to do.  Then you provide a default template for the control, which can easily be crafted by compositing and using builtin presentation features.

There's a learning curve, and there's still some areas I think need some help, but in the general cases this stuff is really quite nice.